Caching strategies
Keep hot data close to the reader to cut latency and shield your datastore.
Visual model
Let repeated reads stop early
Why cache at all
A cache keeps a copy of data somewhere faster or closer than the source of truth. It may live in RAM, at the edge or in the browser.
In read-heavy systems, a high cache hit ratio is a powerful lever. It replaces many database queries with fast memory reads.
The cache also absorbs traffic spikes before they reach the datastore.
Caching adds staleness and complexity. When the source changes, the cached copy may be wrong.
Decide how much staleness you can accept and how you will invalidate the copy.
The common patterns
Pick the write/read pattern that matches your tolerance for staleness and your write volume.
- Cache-aside (lazy): the app checks the cache. On a miss, it reads the DB and fills the cache. This is a simple default, but the first request after an eviction is slow.
- Read-through: the cache itself loads from the DB on a miss, so the app only ever talks to the cache.
- Write-through: writes go to the cache and the DB together. Data stays fresh, but writes are slower.
- Write-back: writes hit the cache and reach the DB later. Writes are fast, but a crash can lose data.
Invalidation and the hard parts
A TTL is the simplest invalidation strategy. You accept that data may be stale for up to N seconds.
For critical data, invalidate or update the cache on every write.
A cache stampede happens when a hot key expires and thousands of requests miss together. The database receives all of them at once.
Prevent it with a short refill lock, staggered TTLs or stale data while the cache refreshes in the background.
See it
Why one expired key can hurt
Key takeaways
- Hit ratio is critical in read-heavy systems. Measure it and protect it.
- Cache-aside is a sensible default. Choose write-through when you need freshness.
- Always define invalidation with a TTL or an on-write update. Plan for stampedes on hot keys.