Cache Invalidation Strategy
Cache invalidation strategy decides when a cached value is no longer valid — TTL, event-driven, version-keyed — so the cache serves fresh data without becoming a correctness liability.
Definition
Cache invalidation strategy is the design decision of how a cache entry is determined stale — a TTL that bounds staleness, an event that invalidates on write, a version key that namespaces by content — so that the cache serves data that is fresh enough for the consumer without the invalidation cost exceeding the cache benefit.
Context and scope
Applied in every cache, from HTTP to application to CDN, where the trade-off between staleness and invalidation cost must be made explicit.
Common misconceptions
- TTL is always sufficient — it bounds staleness but does not ensure freshness; for data where staleness is unacceptable, event-driven invalidation is needed
- Event-driven invalidation is always correct — it is correct if the event fires for every write; a missed write leaves stale data indefinitely
Anti-patterns
- Using a long TTL on data that changes on write, so consumers see stale data for the whole TTL after a change
- Invalidating on every write without checking whether the entry is cached, sending invalidations for entries that do not exist
Related concepts
Authoritative source
What it is
Cache invalidation strategy is the design decision of how a cache entry is determined stale — a TTL that bounds staleness, an event that invalidates on write, a version key that namespaces by content — so that the cache serves data that is fresh enough for the consumer without the invalidation cost exceeding the cache benefit. Applied in every cache, from HTTP to application to CDN, where the trade-off between staleness and invalidation cost must be made explicit. 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.