Interview › Databases & Caching
What is a cache stampede / thundering herd, and how do you prevent it?
Databases & Caching · Intermediate level
Answer
A cache stampede happens when many clients miss the same hot key at once and all hit the backend. I prevent it with request coalescing, TTL jitter, locks, stale-while-revalidate, warmup, and fallback rate limits.
Technical explanation
TTL controls the trade-off between freshness and backend load.
Stampedes are prevented with request coalescing, locks, TTL jitter, stale-while-revalidate, and rate limits.
Invalidation is hard because writes can happen through many services; outbox events make invalidation more reliable after DB commit.
Hands-on example
Cache-aside with stampede protection:
1. GET product:v2:123.
2. On miss, acquire SET product:v2:123:lock 1 NX PX 5000.
3. Lock holder reads RDS and SETEX product:v2:123 300+jitter value.
4. Other callers return stale value or wait briefly.
5. After product update, commit DB then DEL product:v2:123 or publish invalidation via outbox.
Check how well your resume matches the role with our free resume checker— match score, ATS check, and the skills you're missing.
More Databases & Caching interview questions
- What is Amazon RDS, and what does it manage for you versus self-managed databases?
- What database engines does RDS support?
- What is the difference between RDS and Aurora?
- What is Multi-AZ in RDS, and how does automatic failover work?
- How long does an RDS Multi-AZ failover typically take, and what triggers it?
- What is the difference between Multi-AZ and a read replica?
- When would you use a read replica, and can it become a standalone database?
- Can a read replica be in a different region, and why would you do that?