Caching interview question · Most asked
In cache-aside, why can a value be stale even though you delete the key on every write?
Summary
The stale-set race: a reader misses and reads the old row, a writer commits and deletes, then the reader sets the old value — which stays until the TTL. Leases or version-checked sets prevent it; short TTLs bound it.
Longer Answer
Facebook's memcache paper introduced leases for exactly this ('stale sets') and for thundering herds. In Redis, store a version with each value and set only if newer in a Lua script.
Key Points
- Reader set lands after the delete
- Leases / versioned sets
- Short TTLs as a bound
Deep dive: Database Caching at Scale
More most-asked Caching questions
- Explain the main caching patterns: cache-aside, read-through, write-through and write-behind.
- Why is cache invalidation hard, and what strategies help?
- What is a cache stampede (thundering herd) and how do you prevent it?
- How does HTTP caching work (Cache-Control, ETag, CDNs)?
- Explain the difference between cache penetration, cache breakdown and cache avalanche.
- How can a CDN leak one user's data to another, and how do you prevent it?
- In a system design interview, how do you decide what and where to cache?
- How does stale-while-revalidate work, and when is it inappropriate?