Cache Warming
Cache warming pre-populates critical entries before traffic arrives — after deploys, region failovers, and scale events — so first users do not pay cold-cache latency.
Definition
Cache warming is the practice of deliberately filling caches before they face real traffic: prefetching hot keys after a deployment, replaying top URLs at CDN edges, or materializing computed results during a maintenance window. It trades background work during low-stakes periods for guaranteed first-request performance.
Context and scope
Applied on deploy pipelines, DR failover runbooks, new cache cluster bootstraps, and regional expansion. Measured by first-request hit rate after the trigger event.
Common misconceptions
- Caches warm themselves quickly — hot key sets warm in minutes but the first users during that window absorb every miss
- Warming means loading everything — warming the top N by traffic covers most requests; full dumps cover long-tail data nobody requests
- Warming is a one-time job — every deploy, failover, and eviction policy change resets the clock
Anti-patterns
- Warming by alphabetical key order instead of traffic ranking and missing the actual hot set
- Warming through a different code path than production reads, populating entries real requests cannot hit
- Treating warming as optional after failovers, when DR is precisely the coldest-cache moment
Related concepts
Related examples
Authoritative source
https://varnish-cache.org/docs/6.0/users-guide/increasing-your-hitrate.html
What it is
A cold cache serves misses at origin latency. Warming moves that cost to a controlled moment — pre-deploy, during failover rehearsal — by prefetching the entries traffic will request first.
How it works
Rank candidates by request frequency from analytics or access logs, then fetch them through the exact production read path so entry shapes, encodings, and vary variants match. Schedule the warm after cache invalidation and before traffic ramp; repeat on every cold-start trigger.
When to use it
Deploy hooks flushing CDN or app caches, new cache cluster bring-ups, active-passive failovers where the passive cache sat idle, and autoscale events adding cold nodes. Treat warming as part of the deploy definition of done, not an optional follow-up.
Pitfalls
Warming must use the same vary and auth dimensions as real traffic, or it fills unusable variants. Aggressive warming is itself an origin load event — rate-limit and jitter it. Metrics that matter: hit rate in the first N minutes post-event and origin QPS during the same window.