An empty cache shifts load to the backend#
Deployments, failover, a flush, a new region, or a replacement cluster can start with a low hit rate. If traffic arrives at full scale, the origin simultaneously serves users and repopulates the cache.
startup: hit rate low → database load high
steady state: hit rate rises → database load falls| Warming approach | Advantage | Cost |
|---|---|---|
| Lazy from real traffic | Loads only requested data | Users pay cold misses |
| Preload known hot keys | Protects critical paths early | Predictions and preload traffic can be wrong |
| Snapshot / transfer where supported | Restores a larger working set | Platform-specific and can restore stale data |
| Gradual traffic shift | Bounds source load while warming | Needs routing control and spare capacity |
Open a new application region
Preload a small measured hot set, send a small traffic percentage, watch origin QPS and hit rate, then increase traffic. Bulk-loading every historical key can do more backend work than organic misses.
Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.
- Which keys deserve preloading?
- How do you cap warm-up load?
- What signals permit the next traffic step?
- Can safe stale values cross a failover?
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- Caching challenges and strategiesAmazon Builders' Library
Reach this point to mark the lesson as read.