Stale-While-Revalidate
Stale-while-revalidate serves a stale cache entry immediately while refreshing in the background, so the user sees instant response and the next request gets fresh data without a stampede.
Definition
Stale-while-revalidate is the cache strategy where, after the fresh TTL expires, the stale value is served immediately and a background refresh is triggered, so that the user sees no latency from the refresh and the cache stampede is avoided because only one background refresh runs while all concurrent requests get the stale value.
Context and scope
Applied in HTTP caching (Cache-Control: stale-while-revalidate), application caches, and any cache where a slightly stale response is acceptable and the stampede on expiry is a risk.
Common misconceptions
- Stale-while-revalidate is just a longer TTL — a longer TTL serves stale data too; the difference is that SWR refreshes in the background, so the data converges to fresh without a user-visible miss
- It always serves stale data — it serves stale data for the SWR window; after that, if the refresh has not completed, it serves a miss
Anti-patterns
- Serving stale data indefinitely if the background refresh fails, so the cache never converges to fresh
- Triggering a background refresh on every request, recreating the stampede the strategy was meant to avoid
Related concepts
Authoritative source
What it is
Stale-while-revalidate is the cache strategy where, after the fresh TTL expires, the stale value is served immediately and a background refresh is triggered, so that the user sees no latency from the refresh and the cache stampede is avoided because only one background refresh runs while all concurrent requests get the stale value. Applied in HTTP caching (Cache-Control: stale-while-revalidate), application caches, and any cache where a slightly stale response is acceptable and the stampede on expiry is a risk. A cache is a correctness-risky optimization: it trades staleness and coherence complexity for speed, and every cache hit is a bet that the cached value is still valid.
How it works
The cache key must encode every input that affects the result — miss a dimension and you serve the wrong answer. Invalidation is the hard problem: TTLs are a safety net, not a strategy, because they bound staleness but do not ensure freshness. Write-through keeps the cache consistent with the store; write-behind improves write latency at the cost of durability. Eviction policy determines which miss becomes a cache miss under pressure.
When to apply and pitfalls
Apply when the same read dominates and recomputation is expensive. The pitfall is caching without measuring — a cache that has a 99% hit rate but adds latency on the miss path can be a net loss. Another is cache stampede: a popular key expires and every concurrent request recomputes the same value, thundering the backend. Single-flight or stale-while-revalidate prevents this.