Write-Through Cache

A write-through cache updates the cache and the backing data store as part of the same write operation. The write is acknowledged to the caller only after both succeed. This keeps the cache and store consistent, so a read immediately after a write returns the new value from cache.

How It Works

On put(key, value) the cache writes to its own store and synchronously propagates the write to the backing database, typically through a configured writer. Reads are usually served read-through from the same cache. Because the cache is always populated on write, recently written keys are warm, which benefits read-after-write access patterns.

Ordering matters: most implementations write the database first, then the cache, or use a transaction so a failure leaves neither side partially updated. If the database write fails, the cache write is rolled back or skipped to avoid serving phantom data.

When to Use It

Choose write-through when you need strong cache coherence and read-after-write consistency, and when writes are not so frequent that synchronous double-writes dominate latency. It is common for session stores, user settings, and account data where a stale read after an update would be visible and confusing.

Trade-offs

Every write pays the latency of both the cache and the database, so write-heavy workloads suffer. The cache holds data that may never be read again, wasting memory unless paired with eviction and TTLs. If the database and cache are separate systems, a crash between the two writes can still cause divergence; only a shared transaction or idempotent retry fully closes the gap. Compared with write-behind, write-through trades throughput for durability and simplicity: there is no risk of losing buffered writes because nothing is buffered.

Related Patterns

Pair write-through with read-through-cache for a fully managed layer. Write-behind-cache is the asynchronous alternative for higher write throughput, and cache-aside lets the application manage writes and invalidation explicitly. The idempotent-writer pattern makes the dual-write safe to retry.

Example

A user-preferences service uses Redis as a write-through cache. When a user toggles a setting, the service writes to PostgreSQL and Redis in one path; the API returns only after both succeed. The next page load reads the preference from Redis with the new value already present, avoiding a stale read while keeping PostgreSQL as the durable source of truth.