Phil Karlton famously said cache invalidation is one of the two hard problems in computer science. What are the main strategies for invalidating stale cache entries — TTL expiration, explicit invalidation/purge on write, and versioned or keyed cache-busting — and what can go wrong with each in a distributed system with multiple cache nodes?

## Why invalidation is hard Cache invalidation is hard precisely because a cache is a deliberately-created second copy of data, and the moment the original changes, that copy becomes a lie unless something actively corrects it. The difficulty compounds in distributed systems because 'the cache' is rarely one thing — it's often many independent nodes (a cache cluster, CDN edge nodes spread across continents, per-instance local caches), and a single logical piece of data can have copies sitting in several of them simultaneously, each of which needs to learn about a change independently. ## TTL expiration The simplest strategy is **TTL (time-to-live) expiration**: every cache entry is stamped with an expiration time when written, and once that time passes, the entry is treated as gone (either actively swept or simply ignored/refetched on next access). - **TTL's appeal** is that it requires zero coordination — no writer needs to know who's caching what; the cache entry just quietly stops being trusted after its window. - **The cost** is that TTL gives only a probabilistic, worst-case freshness bound, not an actual freshness guarantee tied to when the data really changed: if a value changes the instant after it was cached, it can be served stale for the entire TTL duration, and if it never changes, you're needlessly refetching once the TTL lapses anyway. - **Choosing the TTL value** is itself a trade-off exercise — too long and staleness windows grow uncomfortable; too short and you lose most of the caching benefit and increase load on the origin. ## Explicit invalidation (purge-on-write) Explicit invalidation (purge-on-write) flips the model: the moment the source of truth changes, the writer (or a change-data-capture pipeline listening to the database's write-ahead log) actively deletes or updates the corresponding cache entry so the next read is forced to miss and refetch fresh data. This gives much tighter freshness than TTL alone, because staleness is bounded by 'how fast can the purge propagate' rather than 'how long is the TTL.' The catch is **coordination**: - The writer has to know every cache entry (potentially across multiple keys, if the same underlying data is cached under several derived views — e.g., a product cached both by ID and as part of a category listing) that could hold a stale copy. - In a distributed cache with multiple nodes or a globally distributed CDN, the purge message has to actually reach every node before it's considered done. In practice this means either a fan-out invalidation broadcast (pub/sub to every cache node, or a CDN purge API call per edge region) or accepting eventual consistency — a short window where some nodes have processed the purge and others haven't, so two users hitting different nodes at the same instant can see different answers. - Missed or dropped invalidation messages (a network partition during the broadcast, a cache node that was down when the purge fired) leave permanently stale entries behind unless there's also a TTL as a backstop — which is why most production systems combine purge-on-write with a TTL safety net rather than relying on purge alone. ## Versioned or keyed cache-busting Versioned or keyed cache-busting takes a structurally different approach: instead of trying to delete or update an existing cache entry in place, it makes every distinct version of the data live under its own distinct cache key — typically by embedding a content hash or a monotonically increasing version number into the key (e.g., `product:42:v17`, or a filename like `app.a3f9c1.js` for a static asset). When the data changes, nothing needs to be purged at all: the new version is simply written under a new key that no reader has ever cached, so every read of the new key is guaranteed to be a fresh miss the first time, and any reader still referencing the old key continues to get the old (now-orphaned) value until it naturally ages out via TTL or normal LRU/LFU eviction. This sidesteps the fan-out purge problem entirely — there's no race to propagate a delete to every node, because nodes that haven't heard about the new version simply don't have it cached yet, and correctness comes from readers looking up the current version pointer (often itself cached with a very short TTL, or resolved via a manifest file) rather than from actively evicting stale data. The cost is that old versions linger in the cache consuming memory until they're evicted by the normal policy, and the system needs a reliable, low-latency way to resolve 'what is the current version' everywhere reads happen — that pointer itself can become a smaller-scoped invalidation problem, though a much cheaper one since it's typically a single small key rather than fanning out purges for every changed data item. ## How they layer in production In production, these strategies are typically layered rather than chosen exclusively: 1. **Static assets** use content-hashed filenames (cache-busting) with effectively infinite TTLs since a changed file gets a new name. 2. **Frequently-changing dynamic data** uses purge-on-write for tight freshness with a TTL backstop in case a purge is dropped. 3. **CDNs** specifically often expose an explicit purge API precisely because pure TTL-based expiration is too coarse for content that needs to go live immediately (a breaking news correction, a price change), while pure purge-on-write is too fragile to trust as the only mechanism across globally distributed edge nodes.