Interview › Databases & Caching
What is cache invalidation, and why is it hard?
Databases & Caching · Intermediate level
Answer
Cache invalidation is deciding when cached data is no longer correct and removing or refreshing it. It is hard because writes can come from many paths and caches can exist at multiple layers.
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?