Module 06 · Caching · Lesson 8 of 8
Cache warming
A cold cache is a database outage waiting to happen. How to pre-fill caches before traffic arrives, from access logs, predicted keys or shadow traffic, and how refresh-ahead keeps hot keys from ever expiring into a miss.
Why it matters
A cache with a 95 percent hit rate shields the database from 20 times the load it could handle alone. Restart that cache, add a region, or deploy a new node, and for the first minutes the hit rate is zero: the database sees 20 times its normal traffic and falls over. Warming is how mature systems avoid discovering that on deploy day.
The idea
Cache warming (or priming) fills a cache with likely-needed entries before real traffic depends on it, so the first requests hit instead of miss. The trick is knowing which keys to load, and keeping the warming itself from becoming the load that hurts.
Where the key list comes from
| Source | How | Fits |
|---|---|---|
| Recent access logs | Replay the last N minutes of GETs from a log or a sampled key stream against the new cache | Most systems; cheap and accurate for what was hot a moment ago |
| Known hot set | A ranked list of popular ids (top products, home-page content) maintained by analytics | Catalogue and content sites with a stable head |
| Snapshot of the old cache | Dump keys (and values) from a healthy node and load them into the new one; Redis RDB snapshots or key scans | Replacing or cloning nodes; same data model |
| Predictable schedule | Pre-compute what a job or an event will need (tomorrow's flights, tonight's match) and load it beforehand | Scheduled or event-driven traffic |
| Shadow traffic | Mirror a copy of live reads to the new cache without serving from it, until its hit rate climbs | New regions and clusters; the most faithful warm-up |
Warming without hurting
The warm-up reads come from the database, so an aggressive warmer is just a self-inflicted stampede. Rate-limit the warmer to a fraction of the database's headroom; fetch in batches with multi-get; warm the head of the distribution first (the top one percent of keys usually covers most hits) and let the tail fill from live misses; and make warming idempotent and resumable so a crash halfway does not restart from zero.
Never going cold: refresh-ahead
Warming at startup solves one cold start; refresh-ahead prevents the steady-state version. When a hot key is read and its TTL is nearly over (say under 10 percent remaining), the cache asynchronously re-fetches it in the background and resets the TTL, so popular keys never expire into a miss. Only keys that are actually being read get refreshed, so cold keys still age out. Combined with request coalescing from the stampede lesson, it removes most expiry-driven miss bursts.
Deployment choreography
Treat the cache as part of the release, not an afterthought. Rolling restarts one node at a time keep most of the cluster hot. New nodes join as replicas and warm from their primary before taking reads. Regional launches run shadow traffic for hours before cutover. Config changes that alter key formats (a serializer or a key prefix) are a cold start in disguise and deserve the same treatment, or a dual-read period that tries the new key then the old.