The problem in one picture
A seller changes a price from ₹999 to ₹799. The database has the new price. The cache still says ₹999, and every shopper who hits the cache sees the old one.
Every cache has to answer one question: when data changes, what happens to the copy in the cache? There are three textbook answers, and one that the biggest cache deployments actually use.
Three textbook strategies
Write-through. Write to the cache and the database together, and only then tell the caller "done". Reads right after a write always see the new value. The price: every write waits for two systems, and you fill the cache with data nobody may read.
Use it when data is read soon after it's written and must never look stale, such as a user's settings page right after they save.
Write-back (write-behind). Write to the cache, answer the caller at once, and flush to the database later. Writes are as fast as the cache. The price: if the cache node dies before the flush, those writes are gone.
Use it only where losing a few writes is acceptable or rebuildable, like view counters or telemetry. Your laptop already does this: the operating system keeps changed file pages in memory and writes them to disk later, which is why databases call fsync when they can't afford to lose data.
Write-around. Write only to the database and let the cache fill itself on the next read miss. The cache never holds data nobody asked for. The price: the first read after every write is a miss.
Use it when writes are rarely read straight away, like uploads served through a CDN: the file goes to object storage, and the CDN pulls it on the first request.
What big-tech teams actually do
Facebook's memcache deployment, described in the NSDI 2013 paper Scaling Memcache at Facebook, uses none of the three as written. It runs a look-aside cache: on a read miss the app fetches from the database and fills the cache; on a write the app updates the database and then deletes the key instead of writing the new value.
Why delete instead of update? The cached value is often built by application code from several queries, so the write path doesn't know what the cached value should be. Deleting is simple and safe to repeat. The next reader rebuilds the value (MIT 6.824 notes on the paper).
Deleting creates two new problems, and the paper solves both with leases:
Stale sets. A reader misses and fetches the old value. Before it writes that value to the cache, a writer updates the database and deletes the key. The reader then puts the stale value back, and it stays there until the next write. With leases, a miss hands the reader a lease, a delete cancels it, and the cache refuses the late, stale set.
Thundering herds. A hot key is deleted and thousands of readers miss at once, all hitting the database. With leases, only the first reader gets permission to fetch; the rest wait briefly and retry against the cache.
How to choose in an interview
Ask two questions out loud:
Is data read right after it's written? If yes, populate on write (write-through) or delete-and-refill (look-aside). If no, write-around.
Can you lose a write if a cache node dies? If no, the database must be written before you answer. If yes, write-back is on the table.
Then name the failure mode of what you picked. That's the step most candidates skip.
Success criteria: check yourself
Pick a strategy for each, then compare with the answers below:
A product catalogue where prices change a few times a day and are read millions of times.
A "views" counter on every video.
Profile photos uploaded once and shown later through a CDN.
You've got it if you chose: (1) look-aside with delete on write, because reads dominate and stale prices are costly; (2) write-back, because a few lost increments don't matter; (3) write-around, because the CDN fills on first view. Bonus if you named the failure for each: stale sets, lost counts on node failure, and a slow first view.
Interview angle
Naming a strategy is an L4 answer. Naming it with its failure mode and when you'd switch is L5. Adding how you'd detect it going wrong is L6: watch the cache hit rate after deploys, write latency at peak, and the database read rate when a hot key is deleted.
Next up
Next Thursday: CDNs: write-around caching at the edge, and how they decide what to keep. This week's paid walkthrough, Design a Webhook Delivery System, puts the same "deliver, retry, never lose it" thinking to work across thousands of servers you don't control.