Scaling data / Beginner / 6 min
A cache in front of a database
Cache-aside with Redis: hit rate, TTL, cold starts and what happens to the database without it.
Start the simulation → Change the load, break a part, watch what happens. Free, no sign-up.
In short
- What it is
- Cache-aside: read from the cache first, and on a miss read the database and store the answer with a time to live (TTL).
- Why it matters
- Memory answers in under a millisecond and protects the database from repeated reads of the same data.
- The trade-off
- Cached data can be stale until the TTL ends, and when a hot key expires many requests can hit the database at once (stampede).
- Say it in an interview
- "Cache-aside with a TTL, plus request coalescing or a jittered TTL so a hot key expiring does not flood the database."
Check yourself
In the cache-aside pattern, who loads data into the cache on a miss?
Answer: The application, after reading from the database. The app checks the cache, reads the database on a miss, then writes the result into the cache with a TTL.
What is the main trade-off of a longer TTL?
Answer: Users may see staler data. Items live longer so more requests hit, but changes in the database take longer to show up.
You flush the cache under heavy load and the database falls over. What is this called?
Answer: Cache stampede (thundering herd). Every request misses at once and all of them go to the database together.