Mission
Interactive Simulation
Before we explain anything — play. Push it until it breaks, then fix it.
Load
Cache
Break it
A hot key expires and every request stampedes the DB at once.
What just happened?
A cache in front of the database served the hot data from memory, so only cache misses reached the DB. Database load collapsed and latency dropped, because memory is far faster than disk.
The concept
A cache stores frequently accessed data in fast memory so repeat reads skip the slow backend. Key knobs: cache size (how much of the working set fits), TTL (how long entries stay fresh), and eviction policy (LRU/LFU/FIFO — what to drop when full). Hit rate is the fraction of requests served from cache; higher hit rate means less DB load.
Trade-offs
Nothing is free. Here's what this solution costs you.
In the real world
Conceptually similar to a Redis/Memcached tier in front of a relational database.
Mini quiz
Cache hit rate goes UP when you…
Interview me
The app becomes your interviewer. One question, in your own words.
Boss challenge
Survive a hot-key stampede
10,000 req/s on a 2,000 req/s DB, and a hot key is about to expire.
Goal: Keep DB utilization under 100% through the stampede — without raising DB capacity above 2K req/s.
Use the simulator above with no hints. These checks update live as you play.
Interview question
“Explain cache-aside vs write-through, how you'd pick a TTL, and how you'd prevent a cache stampede on a hot key.”