Cache Invalidation Strategies That Actually Scale

Caching is easy to add and hard to keep honest. The moment content becomes stale, the same layer that made your site fast starts serving yesterday's prices and last week's headlines. Invalidation is the part of the problem nobody enjoys, and the part that decides whether a cache stays trustworthy as the system grows.

Four approaches, in ascending order of effort

Time-based expiry is the cheapest. You accept a window of staleness and let objects age out on their own. It works well for content with predictable rhythms and badly for anything that has to be correct the second it changes.

Purge on write is the intuitive next step: when an editor saves, you tell the cache to drop that key. It is precise, but it requires every writer to know every derived URL, and that list grows quietly until someone forgets one. Teams that track this well tend to document the mapping publicly — the running commentary on caching practice is a reasonable model for how to keep such notes readable.

Tag-based purging fixes the bookkeeping. Each response carries labels describing what it depends on, and a single tag purge clears every page touching that entity. It costs more at the provider level, and it is the point at which most growing platforms stop fighting their cache.

Versioned keys avoid invalidation altogether. You bake a build identifier or content hash into the URL, so a change produces a new key and the old one simply falls out of use. Nothing is ever purged, because nothing is ever overwritten.

• TTL expiry — trivial to run, imprecise by design
• Explicit purge — precise, brittle as URL surfaces multiply
• Tag purge — the practical middle ground for editorial and commerce systems
• Versioned keys — the strongest option, limited to assets you control end to end

Serve stale, then refresh

Whichever route you pick, stale-while-revalidate deserves a place in your headers. It lets the cache answer immediately with a slightly old copy while fetching a fresh one in the background. Users never wait on a revalidation, and your origin never faces a thundering herd the instant a popular object expires.

A short checklist

Write down which objects can be stale and for how long. Give every cached response an owner. Log purges so you can answer "when did this change" without guessing. And test invalidation the way you test deploys — on purpose, before it matters.