In this chapter
We'll compare the three real strategies for handling a cache when the underlying data changes — write-through (strong consistency, slower writes), write-back (fast writes, real risk of loss), and write-around (skips the cache on write) — and land on write-through as the real, correct fix for GreenMart's own stock-count incident.
The Problem in Real Life
Sarah sketches the real fix for the stock count specifically: when the real number changes, the write itself should also update the cache — the event-based signal from two chapters back, made concrete. "But even that has real choices inside it," she says. "Update the cache before, after, or... sometimes not at all?"
Mike raises an eyebrow. "'Sometimes not at all' sounds like it defeats the purpose."
When we write new data, what actually happens to the cache at that exact moment?
Mike
Three Real Answers to "What Happens to the Cache When Data Changes?"
Write-through — strong consistency, real cost
Every write updates the cache and the real store together — always in sync, at the cost of slower writes.
Write-back — fast, with a real risk window
Writes land in the cache immediately; the real store catches up later, risking real data loss if the cache fails first.
Write-Through, Write-Back & Write-Around
When real, underlying data changes, a cache sitting in front of it has three genuinely different real strategies for handling that write — each trading consistency, write speed, and real complexity differently.
- Write-through — update both, right now, together. Every write goes to the cache and the real underlying store (database, disk) at the same time, as one real operation, before the write is considered complete. This keeps the cache and the real data honestly, always in sync — the strongest real consistency guarantee of the three — at the real cost of every write now paying for two operations instead of one, making writes measurably slower.
- Write-back — update the cache now, the real store later. A write lands in the cache immediately and is considered complete right there; the actual underlying store is updated later, asynchronously, often batched with other pending writes. This makes writes genuinely fast, since the slow, real store isn't on the critical path at all — but it creates a real, honest risk window: if the cache fails before that deferred write actually lands, that data is genuinely lost, not just temporarily stale.
- Write-around — skip the cache entirely on write. A write goes straight to the real underlying store, and the cache isn't touched at all — it only gets populated later, the next time that same data is actually read (a real "cache miss populates the cache" pattern). This avoids ever filling the cache with data that gets written once and rarely read again, but means the very first read after a write is guaranteed to miss the cache and pay the real, full underlying cost.
- GreenMart's own real, correct choice. For a stock count — read constantly, and where a stale cache is directly, immediately harmful — write-through is the right real fit: every stock change lands in the cache the instant it happens, at the honest cost of a slightly slower write, which is a real trade GreenMart should happily make for a number customers see on every single page load. Write-back would risk a real, silent data-loss window on a value that matters this much; write-around would guarantee every read right after a stock change still hits the real, slower database.
| Strategy | Write speed | Consistency | Real risk |
|---|---|---|---|
| Write-through | Slower (pays for both writes) | Strong — cache and store always match | None significant — the safest of the three |
| Write-back | Fast (cache write only) | Weaker — store lags behind briefly | Real data loss if the cache fails before the deferred write lands |
| Write-around | Fast (cache untouched) | Cache stays accurate for unread data | First read after a write always misses the cache |
GreenMart's stock count needs write-through specifically: read constantly, and directly harmful when stale, which makes the extra write cost a real, worthwhile trade.
GreenMart now has the real, concrete mechanism behind the event-based invalidation idea from two chapters back — write-through, applied to the exact data that caused the original incident, closes the real gap that let a stale stock count reach a customer's screen in the first place.
Key Takeaway
Write-through, write-back, and write-around each answer "what happens to the cache on a write?" differently — and the right one depends entirely on how badly stale data would actually hurt versus how much extra write cost a system can genuinely afford to pay.
Why This Matters
Every future cache GreenMart places in front of real, changing data — inventory, order status, account balances — needs one of these three real strategies deliberately chosen, not defaulted into. Getting this wrong is exactly how GreenMart's own stock-count incident happened: a cache that was never told what to do the moment the real data underneath it changed.
GreenMart now has all three real write strategies, and the concrete, correct fix for its own incident: write-through for the stock count. The next chapter turns to a completely different real caching layer — HTTP caching, the mechanism controlling how browsers and proxies cache entire pages and responses.