Discussion on "Caching in System Design Interviews: Cache-Aside vs Write-Through vs Write-Back, and the Invalidation Questions Interviewers Ask" | Hashnode
The invalidation follow up is where this question actually gets decided. What worked for me in a real loop: pick TTL as the baseline and treat explicit invalidation as an optimization, not the default. Then name the one case where stale data is unacceptable and handle only that with versioned keys or explicit purges. Trying to invalidate everything perfectly turns into describing a distributed consistency protocol you cannot finish in 40 minutes. Also, write back is almost always the wrong interview answer. The durability follow up kills it unless you have a very specific write heavy case and can say what you lose on a crash.
TTL as the baseline and invalidation as the optimisation is the cleanest way to put it. Naming the one case where stale data actually hurts (price at checkout, permissions) shows judgment without signing up to design a consistency protocol in 40 minutes. Fully agree on write-back too: the crash question ends that answer fast unless you can say exactly what you lose. Thanks for adding the real-loop angle.
Branden Floris
The invalidation follow up is where this question actually gets decided. What worked for me in a real loop: pick TTL as the baseline and treat explicit invalidation as an optimization, not the default. Then name the one case where stale data is unacceptable and handle only that with versioned keys or explicit purges. Trying to invalidate everything perfectly turns into describing a distributed consistency protocol you cannot finish in 40 minutes. Also, write back is almost always the wrong interview answer. The durability follow up kills it unless you have a very specific write heavy case and can say what you lose on a crash.