Cache Invalidation

What is cache invalidation?

Cache invalidation is the problem of determining when cached data has become stale and must be refreshed or removed so that consumers don’t keep seeing outdated information. Caching stores a copy of data somewhere fast (in memory, in a CDN, in the browser) to avoid recomputing or re-fetching it — but the moment the underlying source data changes, every cached copy is potentially wrong, and invalidation is how you decide which copies to expire and when. It’s famously cited (via Phil Karlton’s quip that “there are only two hard things in computer science: cache invalidation and naming things”) as one of computing’s genuinely hard problems — and the joke endures because it’s true.

Why it’s genuinely hard — the fundamental tension

The difficulty is a fundamental tradeoff between freshness and performance with no perfect answer. Invalidate too aggressively — expire cached data too quickly or too often — and you lose the benefit of caching: you’re constantly re-fetching or recomputing, defeating the point and hammering the backend the cache was meant to protect. Invalidate too conservatively — keep cached data too long — and you serve stale, wrong data: users see outdated prices, old content, deleted items, or another user’s information. Every caching system lives on this spectrum, and the “right” answer depends on how tolerant the specific data is to staleness (a stock price vs a blog post’s footer) — which is why there’s no universal solution. The classic strategies each pick a point on the tradeoff: TTL (time-to-live) expires entries after a fixed duration (simple, but you’re guessing how long data stays valid — during the TTL window you may serve stale data, and after it you may re-fetch unnecessarily); event/write-based invalidation actively purges or updates cached entries when the source changes (fresher, but requires reliably knowing about every change and touching every cache that holds the data — hard in distributed systems with many cache layers); and versioning/cache-busting (changing the key/URL when content changes, e.g., fingerprinted asset filenames, so new content has a new key and old caches simply age out harmlessly).

Where it bites, and the practical realities

Cache invalidation shows up everywhere caches do, and each layer has its own machinery and pitfalls. CDN caching: purging edge caches globally when content updates (CDNs offer purge APIs, but a global purge takes time and mass-purging can stampede the origin). Browser caching: Cache-Control headers and asset fingerprinting (the fingerprint-the-filename trick is the clean solution — new build, new filename, no stale JS/CSS). Application caches (Redis/Memcached): invalidating or updating keys on writes. The hardest failure modes are distributed-systems ones: keeping multiple cache layers consistent (browser + CDN + app cache all holding copies), avoiding cache stampedes (a popular key expiring so every request simultaneously hits the backend to repopulate it — mitigated with request coalescing, staggered TTLs, or serving-stale-while-revalidating), and the thundering herd when many entries expire at once. A widely-used pragmatic pattern is stale-while-revalidate: serve the slightly-stale cached copy immediately (fast) while asynchronously refreshing it in the background (eventually fresh) — accepting brief staleness to avoid both latency and stampedes. The recurring mistakes: choosing TTLs by guesswork without regard to how stale the data can safely be, forgetting a cache layer so it serves stale data others have purged, and mass-invalidating in a way that stampedes the origin.

What people get wrong

• Guessing TTLs — setting expiry without matching it to how stale the data can safely be either serves wrong data or re-fetches needlessly; tune to the data’s staleness tolerance.
• Forgetting a cache layer: browser, CDN, and app caches all hold copies — invalidating one while another serves stale data causes baffling “I updated it but users still see the old version” bugs.
• Invalidation stampedes — expiring a hot key (or mass-purging) sends every request to the backend at once; use request coalescing, staggered TTLs, or stale-while-revalidate to smooth it.

Primary source: MDN: HTTP caching