Interview › Databases & Caching
What are common caching patterns (cache-aside, read-through, write-through, write-behind)?
Databases & Caching · Intermediate level
Answer
Cache-aside loads from the DB on miss, read-through lets the cache layer load, write-through writes cache and DB synchronously, and write-behind writes to cache first then flushes asynchronously. Each pattern trades consistency, latency, and loss risk differently.
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?