Absorbing Read Load
A cache stores hot results in fast memory so repeated reads skip the database entirely. With a high hit rate, a small cache can absorb the majority of read traffic, protecting the database and cutting latency.
Cache Aside
The most common pattern is cache aside. On a read, the application checks the cache first.
- Hit Return the cached value.
- Miss Read from the database, store the result in the cache, then return it.
On a write, the application updates the database and invalidates the cached key so the next read refreshes it.
The Hard Parts
- Invalidation Keeping the cache consistent with the database is famously hard. A stale entry serves wrong data until it expires or is evicted.
- Thundering herd When a popular key expires, many requests miss at once and stampede the database. A lock or single flight rebuild lets one request repopulate while others wait.
- Cold start An empty cache after a restart offers no protection until it warms up.
A time to live bounds staleness by expiring entries automatically, trading freshness for simplicity.
Key idea
A read cache absorbs hot traffic with cache aside lookups, but invalidation, thundering herd, and cold starts are the real challenges.