Caching
Cache invalidation: multiple-choice review
Crux Multiple-choice synthesis across cache invalidation — TTL jitter, the set-after-delete race, dual-write, delete vs update, and which write strategy preserves read-your-writes.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one is a decision you make in a real incident — not a strategy to name, but a staleness gap to weigh against what your product can tolerate.
Goal
Confirm you can connect TTL stampedes, the dual-write problem, the set-after-delete race, and the write-path strategies — the synthesis the lesson built toward: every strategy ships a different staleness.
Quiz
Completed
1,000 app servers cache the same hot key with an identical 300s TTL, all warmed in one deploy. At T=300 the origin gets hammered for ~100ms. What is the cleanest first fix, and why does it work?
Heads-up Shortening the TTL multiplies origin load and does nothing about synchronization — all 1,000 servers still expire in the same window, just ten times as often.
Heads-up Removing the TTL throws away your backstop for missed purges. The stampede is a synchronization problem; you fix it by scattering expiries, not by removing them.
Heads-up More nodes do not help when every node expires the same key at the same instant and all miss to the same origin simultaneously.
Quiz
Completed
You use cache-aside with delete-on-write: update the DB, then DEL the key. A user reports their profile edit reverting for hours. What is the most likely root cause?
Heads-up DEL is atomic for a single key. The bug is timing across two concurrent requests, not a partial delete of one key.
Heads-up Redis does not restore deleted keys mid-operation; the stale value comes from a concurrent reader's SET, not from persistence.
Heads-up A TTL only expires keys — it never recreates them with old data. The stale write is a racing reader repopulating the key.
Quiz
Completed
Why is deleting the cache key on write the senior reflex, rather than updating it with the new value?
Heads-up The difference is correctness, not speed. DEL avoids an ordering hazard: two value-writes can land cache-first in the opposite order from their DB commits, leaving the cache permanently disagreeing with the DB.
Heads-up Keeping it warm is a hit-rate argument, not a correctness one. Updating reintroduces the write-ordering race that delete-then-repopulate sidesteps.
Heads-up DEL avoids writer-vs-writer ordering bugs, but it does NOT close the set-after-delete race against a concurrent reader — that still needs double-delete, leases, or write-through.
Quiz
Completed
Your team actively invalidates on every write and proposes removing the TTL entirely 'since we always purge.' What breaks?
Heads-up They can diverge whenever the DEL fails but the DB commit succeeds. The DB and cache are two systems with no shared transaction, so the purge is not guaranteed.
Heads-up The risk here is correctness (permanent staleness on a missed purge), not hit rate. The TTL exists as a freshness backstop, not for eviction.
Heads-up Eviction policy (LRU/LFU) handles memory pressure independently. The reason to keep a TTL here is to bound the damage of a purge that silently failed.
Quiz
Completed
A user edits their own profile and must immediately see the new value (read-your-writes required). Which write strategy holds with the least racing risk?
Heads-up Write-around is the worst choice here: the writer's own next read is a guaranteed miss, and any lingering stale entry serves the old value. It is for data rarely read soon after writing — the opposite case.
Heads-up It is read-your-writes-friendly on the cache, but it opens a durability window: if the node dies before the async flush, the committed-looking edit is lost. Reserve it for tolerant data like counters.
Heads-up Usually fine, but exposed to the set-after-delete race, so the writer can still see their old profile. It needs delayed double-delete or leases before it is safe for strict read-your-writes.
Quiz
Completed
A hot key under cache-aside keeps hitting the set-after-delete race on every profile edit. You want the strongest fix that also reduces origin load. What do you reach for?
Heads-up A longer TTL makes the stale window worse, not better — once the race fires, the wrong value sits even longer. It also does nothing about origin load on a miss.
Heads-up Updating reintroduces the writer-vs-writer ordering hazard and still races with the reader's read. It trades one race for another rather than closing the set-after-delete window.
Heads-up That removes the race by removing the cache, but a hot key is exactly where you most need the cache — it sends full load to the origin, the problem leases were designed to solve.
Recap
The through-line is one sentence: invalidation is choosing which staleness you ship. TTL is the cheap floor — bounded but prone to synchronized stampedes you defuse with jitter. Event-driven purge cuts staleness to the write but is a dual-write, so you keep a TTL as the backstop for every missed DEL. Delete beats update because it is idempotent and order-independent, but it still races with a concurrent reader — the set-after-delete race — closed by delayed double-delete, by leases (which also slashed Facebook’s hot-key load), or by funneling writes through the cache. And the write strategy you pick is a read-your-writes decision: write-through holds it, write-around breaks it, write-behind risks durability.