Cache invalidation: free-recall review
Free-recall prompts across cache invalidation. Answer each from memory first — the set-after-delete race, TTL jitter, dual-write, and the write strategies — then reveal the model answer and compare.
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the consistency model stick when an incident hits at 3am.
Reconstruct the unit’s spine — why invalidation is a staleness choice, the set-after-delete race and its three fixes, why a TTL stays even with active purge, and what each write strategy buys — without looking back at the lesson.
- 01Why is cache invalidation framed as 'choosing which staleness you ship' rather than a problem you can fully solve?
- 02Walk through the set-after-delete race step by step, and name the three ways to close it in rising order of cost.
- 03Why keep a TTL even when you actively invalidate on every write, and what is the dual-write problem?
- 04What is the thundering herd from synchronized TTL expiry, and how do jitter and probabilistic early refresh defuse it?
- 05Why delete the cache key on write rather than update it with the new value?
- 06Contrast write-through, write-behind, and write-around: what each buys and breaks.
If you reconstructed each answer from memory, you hold the unit’s spine: invalidation is choosing which staleness to ship because cache and DB share no transaction; the set-after-delete race is the production trap, closed by double-delete, leases, or write-through; a TTL stays even with active purge as the backstop for the dual-write that silently fails; synchronized expiry stampedes the origin, defused by jitter and probabilistic early refresh; delete beats update because it is idempotent and order-independent; and the write strategy — through, behind, around — is a read-your-writes-vs-durability decision.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.