Caching: Layers, Strategies, Eviction

A cache keeps frequently-read data in fast memory so you can skip the slow database. The animation is a two-lane race that makes the payoff concrete: request A takes the short lane through a Redis box and finishes in ~1ms; request B takes the long lane to the database cylinder and takes ~30ms. That 20-50x speedup is why "add a cache" is the most common answer to a latency requirement.

The default pattern to name is cache-aside: the app checks the cache first, and on a miss (the data is not there) it reads the database and writes the result into the cache for next time. It covers roughly 90% of cases.

Then watch the hard part. A write hits the database, and a red "stale!" flash sits on the cache — the cache still holds the old value — until an invalidation bolt clears the entry. That is invalidation: either delete the cached entry when the underlying data changes, or let it expire via a TTL (time to live). Interviewers always follow "add a cache" with "how do you keep it consistent?" — this flash is your answer.

Last piece: when the cache fills up, something must go. The default eviction policy is LRU — throw out the least recently used entry first.