What Is Cache Invalidation?

What is cache invalidation?

Caches exist at every layer of computing — CPU caches, application memory, Redis tiers, CDN edges — and all of them share the same weakness: the cache does not automatically know when the source changed, and the source does not automatically know who is holding copies. Closing that knowledge gap is the entire discipline of cache invalidation, and it is famously difficult. The line widely attributed to Phil Karlton — "there are only two hard things in computer science: cache invalidation and naming things" — endures because the problem combines distributed state, timing, and failure handling in a small surface area.

Strategies fall into three broad families: expiration-based (entries die on a timer, regardless of whether the source changed), write-triggered (the code path that writes the source also updates or removes the cached copy), and event-driven (a change stream from the source drives invalidation asynchronously). Most production systems combine them — for example, event-driven invalidation with a TTL as a safety net against missed events.

How cache invalidation works

• TTL (time-to-live): each entry expires after a fixed interval. Simple and failure-tolerant, and staleness is bounded by the TTL — but every read inside the window can be stale, and shortening the TTL trades staleness for load on the source.
• Cache-aside with explicit delete: the application deletes the cache key when it writes the source; the next read misses and repopulates. Widespread, but subject to a classic race condition: a reader that fetched the old value from the source just before the write can repopulate the cache with stale data just after the delete, leaving the stale value in place until the next invalidation or expiry.
• Write-through: writes go through the cache to the store synchronously, so that cache is never stale with respect to its own writers. The costs are write latency and the fact that it says nothing about other caches holding the same data.
• Event-driven / CDC: the cache subscribes to a change stream from the source — often via change data capture — and invalidates or updates entries as events arrive. Staleness is bounded by pipeline propagation lag rather than a timer, typically a much tighter bound than a practical TTL.

Expiration-based schemes carry one more operational hazard: when a popular key expires, every concurrent reader misses at once and stampedes the source — the thundering herd problem. Mitigations include request coalescing (one reader refreshes while others wait), jittered TTLs, and serving the stale value while a refresh runs in the background.

Why cache invalidation matters in real-time systems

For a dashboard, a value that is thirty seconds stale is cosmetic. For an automated decision, staleness has a hard budget: the decision is only correct if the cached context is fresh within the window in which the decision commits. A velocity counter cached with a 60-second TTL is, by construction, up to 60 seconds behind — and a burst of activity inside that window is invisible to every decision that reads the cached value. What separates harmless from harmful staleness is examined in what is stale data.

The structural problem compounds when multiple services each maintain their own cache of the same source. Each cache sits at a different propagation stage — one refreshed two seconds ago, another forty seconds ago — so the services see different versions of reality and can make mutually contradictory decisions about the same entity. No per-cache invalidation policy fixes this, because the issue is not any single cache's staleness but the divergence between the copies. That is a coherence problem rather than an invalidation problem, and it is covered under cache coherence.

FAQ