Write-Through Cache
establishedSummary
Write to the cache and the database synchronously, in the same operation, before acknowledging the caller: the cache is always populated with the value that was just durably written, at the cost of the caller waiting on both writes.
Problem
Cache-aside leaves a window, immediately after every write, where the cache is either stale or empty until the next read repopulates it; some workloads cannot tolerate that window and need the cache to already hold the correct value the moment a write is acknowledged.
Description
In write-through caching, every write goes to the cache and the database as one logical operation: the cache entry is updated (or created) at the same time the database row is written, and the caller does not receive an acknowledgment until both have completed. The next read is guaranteed to hit a warm, consistent cache entry, because the cache was populated at write time rather than lazily on a subsequent miss.
Contrast with the other two write strategies covered elsewhere in this knowledge base: - Cache-aside: the application writes to the database only; the cache is left
stale or explicitly invalidated, and the next read repopulates it lazily on a
miss. Simplest model, but every write leaves a window where the cache is either
empty or stale until the next read.
- Write-behind: the application writes to the cache only, acknowledges the caller
immediately, and a background process flushes to the database asynchronously.
Fastest write latency, but unflushed writes are lost if the cache fails before
the flush completes.
- Write-through: writes go to cache and database synchronously before
acknowledging. The caller pays the cost of both writes on every request, but
the cache is never stale relative to the database and there is no unflushed-
write durability risk.
Because both writes happen inside the same logical operation but are not transactional across two different systems, write-through introduces a dual-write failure window: if the database write succeeds but the cache write fails (or vice versa), the cache and database diverge. This is the same class of problem as publishing an event after a database write without a transactional outbox — see `dual_write_inconsistency`. Mitigating it requires either accepting eventual reconciliation (a subsequent cache-aside-style invalidation on read, as a safety net) or ordering the two writes so that a failure on the second write can be detected and the first write's effect explicitly invalidated rather than left in an unknown state.
Tradeoffs
Cache is always warm and correct immediately after a write; no invalidate-then-repopulate window
Caller waits on both the cache write and the database write before acknowledgment
Database write is synchronous and durable before acknowledgment; no unflushed-write loss window like write-behind
A cache write succeeding while the database write fails, or vice versa, leaves the two diverged with no automatic reconciliation
Every written key is cached regardless of whether it is ever read again, unlike cache-aside's read-driven population
When to use
Reads immediately following a write must see the new value from cache, not a stale or missing entry
Cache-aside's invalidate-then-lazily-repopulate window is unacceptable when the very next read is expected to hit a warm, correct cache entry
Write volume is low enough that the added write-path latency is acceptable
Every write now pays for both the cache write and the database write before acknowledging; high write-volume paths absorb this cost on every request
Data must never be lost even if the cache fails immediately after a write
Unlike write-behind, the database write is synchronous and durable before acknowledgment, so a cache failure after the write does not lose data
When not to use
Write latency is the primary bottleneck
Write-through adds the cache write to the critical path on top of the database write; write-behind or cache-aside are both faster for the write path
Most written keys are never read again, or are read much later than they are written
Populating the cache on every write wastes cache memory on entries that will be evicted before they are ever read, displacing genuinely hot keys
The two writes cannot be kept from diverging under partial failure
If the operational discipline to detect and reconcile a cache-write/database-write split does not exist, write-through silently trades cache-aside's staleness window for an unbounded divergence risk
Operational Requirements
Detect and handle the case where one of the two writes succeeds and the other fails
Without explicit handling, a partial failure leaves the cache and database silently diverged in either direction, indistinguishable from a correct write until the divergence is observed
Set a TTL on written keys as a safety net, the same as cache-aside
Write-through does not exempt the cache from needing an expiry bound; an undetected divergence should still self-heal once the TTL expires
Monitor cache-write failure rate separately from database-write failure rate
The two writes fail independently; conflating their error rates hides which side of the dual write is actually degrading
Characteristics
Technologies
Canonical
Alternatives
Relationships
Evolves from
Complements
Basis
Well-understood caching strategy with a clear latency/consistency tradeoff against cache-aside and write-behind; the dual-write failure window is documented by analogy to the outbox/dual-write literature rather than a write-through-specific source, so confidence is held slightly below the longer-established cache-aside and write-behind entries pending a dedicated citation pass.