How Caching Works
IntermediateA cache stores a copy of data somewhere faster to read than the original source, so repeated requests skip expensive work. Caching is one of the highest-leverage tools in system design: it cuts latency and offloads databases. The hard parts are not storing data but deciding when to update or remove it (invalidation), how to evict when full (LRU/LFU), and how to avoid everyone rebuilding the same entry at once (a stampede).
Think of a cache as keeping notes on your desk
Instead of walking to the archive room (the database) every time you need a figure, you jot frequently-used numbers on a sticky note on your desk (the cache). Next time, you glance at the note — instant. The trouble starts when the archived figure changes: your note is now wrong (stale). So you either date the note (TTL) or update it whenever the archive changes (invalidation). Caching is easy; keeping the note honest is the real work.
Step by Step
Key Concepts
Cache-Aside
The app manages the cache: read from cache, on a miss load from the database and populate the cache, and invalidate on write. The most common and flexible pattern.
Write-Through vs Write-Back
Write-through writes to cache and database synchronously (consistent, slower). Write-back writes to cache first and flushes to the database later (faster, but data can be lost on failure).
Eviction Policy
How a full cache chooses what to remove. LRU drops the least recently accessed entry; LFU drops the least frequently used. The right policy depends on access patterns.
Cache Stampede
When a popular entry expires and a flood of concurrent misses all hit the origin at once. Prevented with request coalescing (a lock), jittered TTLs, or serving stale while refreshing.
Key Facts
- Caching is often the cheapest way to cut latency and database load by an order of magnitude — but only correct if invalidation is handled.
- There are only two hard things in computer science, the joke goes: cache invalidation and naming things. Stale data is the number-one caching bug.
- Caches exist at many layers: CPU, browser, CDN, reverse proxy, application (Redis/Memcached), and inside the database — each closer layer is faster but smaller.
Real-World Applications
Caching database reads with Redis
A product page that reads the same product thousands of times per minute caches it in Redis with a short TTL — turning thousands of database hits into one, and serving the rest from memory in microseconds.
Session storage
Storing user sessions in a fast in-memory cache lets any app server serve any user without a database round trip per request, enabling stateless horizontal scaling.
Frequently Asked Questions
What is the difference between cache-aside and write-through caching?
In cache-aside, the application loads data into the cache on a miss and invalidates it on writes — the cache is populated lazily. In write-through, every write goes to both the cache and the database synchronously, so the cache is always warm and consistent, at the cost of slower writes. Cache-aside is more common and flexible.
What is cache invalidation and why is it hard?
Cache invalidation is removing or updating cached data when the underlying source changes, so clients do not read stale values. It is hard because data can change from many places, entries may be spread across layers, and getting it wrong causes users to see outdated information. TTLs and event-driven invalidation are the common approaches.
What is a cache stampede?
It happens when a popular cache entry expires and many concurrent requests all miss and hit the origin database at the same moment, overwhelming it. Prevent it by letting only one request rebuild the entry while others wait (request coalescing), jittering TTLs so entries do not all expire together, or serving slightly stale data during a background refresh.
What eviction policy should I use?
LRU (least recently used) is a solid default and works well when recent data is likely to be reused. LFU (least frequently used) suits workloads with stable hot items. Choose based on whether recency or frequency better predicts future access for your data.