What is a cache stampede and how do you prevent it?
A cache stampede happens when a popular key expires and many requests miss at once, all hitting the database together. Prevent it with request coalescing or locks, jittered TTLs, and refreshing entries before they expire.
Explain it simply
Imagine the IPL ticket page. The cached result for "available seats" expires at 7:00:00. In the next second, 10,000 requests arrive, all find the cache empty and all query the database. The database collapses, which makes the cache even slower to refill.
Ways to prevent it:
- Request coalescing (single flight): the first miss recomputes; the others wait for its result instead of querying.
- Locking: a mutex per key so only one request rebuilds the value.
- TTL jitter: add a random few seconds to expiry so many keys do not expire together.
- Early refresh: a background job renews hot keys before they expire.
- Serve stale while revalidating: return the old value briefly while one worker refreshes.
Related problems: cache penetration, where requests for keys that do not exist always miss, handled with negative caching or a Bloom filter; and cache avalanche, where many keys expire together, handled mostly with jitter.
Example
Without protection:
10,000 requests miss -> 10,000 database queries
With single-flight:
1 request recomputes (say 80 ms)
9,999 requests wait 80 ms and share the result
Database sees 1 queryWhat to say in the interview
"A stampede is many concurrent misses on one expired hot key overwhelming the database. I prevent it with single-flight or per-key locks, randomised TTLs, background refresh and serving stale data briefly. For nonexistent keys I add negative caching."