Scaling Reads and Writes
Caching Strategies and Invalidation
Where caches sit, how each write strategy behaves under failure, why hit ratio is non-linear, and how to stop a stampede.
Medium13 min read
By the end of this chapter
- Place a cache at the right layer for the data being cached
- Implement cache-aside with delete-on-write and explain its remaining race
- Compute database load from cache hit ratio and explain why small drops hurt
- Prevent stampedes with request coalescing, jittered TTLs and stale-while-revalidate
Where a cache can live
The Data section introduced the four write strategies and the thundering herd. This chapter goes underneath them, starting with the question that comes before strategy: where in the request path the cache sits, because that decides who can invalidate it.
| Layer | Example contents | Who can invalidate it |
|---|---|---|
| Client / browser | Static assets, API responses with cache headers | Nobody — only expiry or a new URL |
| CDN | Images, scripts, public pages | You, via purge APIs, slowly and coarsely |
| In-process | Config, small lookup tables | Each instance separately |
| Shared cache cluster | Sessions, rendered fragments, query results | You, per key, immediately |
Sign in to keep a note here. It is free, and nobody else can see it.
Sign inYou’ve reached the end
What this chapter was for:
- The database sees the misses, so a hit ratio falling from 99% to 95% means five times the database load.
- On write, delete the cache entry rather than updating it — and still keep a TTL as a safety net.
- Write-through keeps caches warm; write-back trades durability for write speed.
- A stampede is many misses for one key at once; coalescing turns them into a single load.