1 Overview
Cache-aside and write-through are two ways to keep a cache and a primary data store consistent, and they differ mainly in who is responsible for filling and updating the cache. In cache-aside, the application reads the cache first, falls back to the store on a miss, and then writes the value into the cache. Writes go to the store, and the application usually deletes the corresponding cache key rather than updating it. In write-through, the application writes through the cache layer, which updates both the cache and the backing store in the same logical operation, so reads almost always find a populated entry.
The appeal of cache-aside is that it caches only what is actually requested, which keeps memory use proportional to real read demand. The appeal of write-through is that it removes a whole class of application-level invalidation bugs, because the cache is updated as part of the write path rather than as an afterthought. Neither is universally better; the right choice depends on your read-to-write ratio, how tolerant your workload is of stale reads, and how much write latency you can absorb.
A useful way to frame the decision is to ask what failure you would rather debug. Cache-aside failures tend to look like stale reads after a missed invalidation or a thundering herd after a popular key expires. Write-through failures tend to look like elevated write latency, cache nodes holding entries that are never read, and partial writes where the cache and store disagree after an error. Both strategies are legitimate; the mistake is choosing one by habit instead of by workload shape.
2 Where the common advice breaks down
The most common advice is that cache-aside is the default and write-through is for write-heavy or consistency-sensitive systems. That rule of thumb hides the fact that cache-aside is not one strategy but several, and its behavior changes dramatically depending on whether you delete or update on write, whether you use a TTL, and whether you protect against stampedes. A cache-aside implementation that updates the cache on write instead of deleting it can produce worse staleness than a naive write-through, because concurrent writers can interleave and leave an old value resident indefinitely.
Another breakdown is the assumption that write-through guarantees consistency. It does not, unless the cache and store are updated atomically or you have a repair path for partial failures. If the cache write succeeds and the store write fails, or vice versa, you have a divergence that a TTL may eventually paper over but will not fix immediately. Write-through narrows the staleness window; it does not eliminate the need to reason about failure modes.
The advice also ignores read amplification. Write-through populates the cache on every write, including writes to keys that are never read again. For workloads with high key cardinality and low re-read probability, that is pure overhead: extra memory pressure, extra eviction churn, and extra write latency for no read benefit. Conversely, cache-aside advice often ignores cold-start behavior, where a freshly deployed or restarted cache serves a burst of misses that can overwhelm the backing store. The honest position is that both strategies need explicit handling for the failure modes the other one is famous for.
3 How the mechanism actually works
In cache-aside, the read path is a lookup followed by a conditional fill. The application asks the cache for a key; on a hit it returns the value, and on a miss it reads from the store, writes the result into the cache with a TTL, and returns it. The write path typically deletes the key after the store write commits, so the next read repopulates it. The ordering matters: deleting after the store write avoids the race where a concurrent reader repopulates the cache with the old value before the store is updated. Even so, a read that started before the write can still land after the delete, which is why TTLs and versioned keys exist as backstops.
In write-through, the write path updates the cache and the store together, and the read path is a simple cache lookup with a miss fallback to the store. Because writes populate the cache, the read path rarely needs fill logic, which simplifies read-side code and tends to produce more predictable hit rates for keys that are written and then read. The cost is that every write now touches two systems, so write latency is bounded by the slower of the two, and the cache must be available for writes to succeed unless you implement a bypass.
A related variant, write-behind or write-back, defers the store write and is sometimes conflated with write-through. It is a different trade-off: lower write latency and higher risk of data loss on cache failure. Keeping the three distinct matters, because the failure and durability characteristics of write-through and write-behind are not interchangeable, and choosing the wrong label can lead to the wrong operational assumptions.
4 Trade-offs you are really making
The first trade-off is read latency versus write latency. Cache-aside keeps writes cheap because they only touch the store, but pays on reads with miss handling and fill logic. Write-through keeps reads cheap and predictable because the cache is usually warm, but pays on every write with an extra network round trip and the possibility of partial failure. If your workload is read-dominated and writes are rare, cache-aside usually wins on cost. If reads are latency-critical and writes are frequent enough that misses are common, write-through can be the better fit.
The second trade-off is memory efficiency versus freshness. Cache-aside uses memory in proportion to actual read demand, so it tends to have a higher ratio of useful entries. Write-through uses memory in proportion to write volume, which can be much larger and includes keys that are never read. In exchange, write-through gives you a smaller staleness window and less application-level invalidation logic. The question is whether that freshness is worth the memory and write-path cost for your specific access pattern.
The third trade-off is complexity distribution. Cache-aside pushes complexity into application code: every read path needs fill logic, every write path needs invalidation logic, and every team needs to agree on the ordering rules. Write-through pushes complexity into the cache layer and the write path, which can centralize correctness but also creates a hard dependency on cache availability for writes. Neither is free; you are choosing where the complexity lives and who owns it. A hybrid is common in practice: write-through for small, hot, frequently updated objects, and cache-aside for large, read-mostly objects where populating on write would be wasteful.
5 Implementing it correctly
For cache-aside, the safest write pattern is delete-on-write rather than update-on-write, followed by a TTL. Deleting avoids the interleaving problem where two writers race and leave a stale value resident. Use a short, jittered TTL so that even a missed invalidation self-heals, and add jitter to prevent synchronized expiry across many keys. Protect hot keys with request coalescing or a short-lived lock so that a single miss does not trigger a stampede against the store. Finally, make sure your fill logic handles the case where the store returns nothing, because caching a negative result without a short TTL can pin a wrong answer in place.
For write-through, decide explicitly what happens when the cache write succeeds and the store write fails, and vice versa. The common approaches are to write the store first and then the cache, to write the cache first and treat the store as authoritative on read, or to use a transactional outbox or repair job that reconciles divergence. Whichever you choose, document it, because the failure semantics are the part that operators will need at three in the morning. Also consider a bypass path so that writes can still succeed when the cache is unavailable, even if that means temporarily degrading to store-only writes.
In both cases, keep key design and serialization stable, because changing the shape of a cached value without versioning the key is a classic source of silent corruption. Use namespaced or versioned keys so that a schema change can be rolled out by writing new keys while old ones expire. And instrument the cache layer from day one: hit rate, miss rate, eviction rate, fill latency, and write-path error rate are the minimum signals you need to tell whether the strategy is behaving as intended.
6 Measuring whether it helped
Start with the hit rate, but do not treat it as the goal by itself. A high hit rate on cheap-to-compute values may not matter, while a moderate hit rate on expensive queries can be a large win. Segment hit rate by key family, because an aggregate number can hide a hot subset that is missing constantly. Pair hit rate with miss cost, measured as the latency and load the backing store absorbs on a miss, so you can estimate the actual benefit rather than assuming it.
For cache-aside, watch the fill path specifically: how often misses trigger store reads, how long fills take, and whether concurrent misses on the same key are being coalesced. A rising miss rate after a deploy often means a key format change or a TTL change rather than a traffic change. For write-through, watch write latency and write error rates, and compare them against the read-latency improvement. If write latency grows faster than read latency improves, the strategy is not paying for itself. Also track cache memory and eviction churn, because write-through can inflate both.
Finally, measure staleness directly where you can. For cache-aside, compare a sampled set of cached values against the store to estimate the stale-read window. For write-through, track divergence between cache and store after failures and confirm that your repair path actually converges. The honest test is not whether the cache is faster in a benchmark, but whether the end-to-end request distribution, error rate, and store load improved under real traffic. If they did not, the strategy is adding complexity without a corresponding benefit, and it is worth revisiting the choice.
7 Frequently asked questions
Is cache-aside always the safer default? No. It is a reasonable default because it caches only what is read and keeps writes simple, but it pushes invalidation correctness into application code. If your team cannot consistently implement delete-on-write, TTLs, and stampede protection, write-through may produce fewer stale-read incidents even though it costs more on writes.
Does write-through eliminate stale reads? It narrows the window but does not eliminate it. If the cache and store are not updated atomically, a failure between the two writes leaves them divergent until a TTL expires or a repair job runs. Treat write-through as a freshness improvement, not a consistency guarantee.
Can I combine them? Yes, and many systems do. Write-through suits small, hot, frequently updated objects where the read path benefits from a warm cache. Cache-aside suits large, read-mostly objects where populating on write would waste memory. The two can coexist behind a single interface as long as the failure and invalidation semantics are documented per key family.
What about write-behind? Write-behind defers the store write, which lowers write latency but risks data loss if the cache fails before the store is updated. It is a different trade-off from write-through and should not be treated as a drop-in substitute when durability matters.
How long should TTLs be? Long enough to absorb read bursts, short enough that a missed invalidation self-heals within your tolerance for staleness. Add jitter, and prefer per-key-family TTLs over one global value, because volatile and stable data have different freshness needs.