Domains, CDN & Web Delivery

Cache Invalidation

Definition

Cache invalidation is the problem of making a change visible when copies of the previous version are held in places you do not control — edge nodes, corporate proxies and, most stubbornly, the browsers of people who have already visited. The first approach is a purge: you ask the CDN to mark stored copies of a path as stale, either one path at a time, by tag, or by wiping everything. The second is cache busting, where you never overwrite a file at all but publish the new version under a new address, typically with a content hash in the name, so app.4f2c9a.js replaces app.8b1e33.js and the old name is simply never requested again. A purge reaches shared caches. It does not reach a browser that was told, via Cache-Control, to keep its copy for a year, and that asymmetry is the whole subject.

Why It Matters

A purge you believe in and a browser cache you cannot reach is how sites end up half broken for weeks. Set max-age=31536000 on a stylesheet, change it, purge the network, and every returning visitor still renders the old one until their year is up. Worse, the mix is inconsistent: returning visitors combine new markup with an old stylesheet, producing layout faults you cannot reproduce. Purges also cost hit ratio, since a full wipe on a busy site sends every subsequent request to the origin until the caches refill, which can mean a tenfold load spike for several minutes. Renaming the file avoids all of this because nothing has to be invalidated.

How It Works

A purge is an API call or a dashboard action naming paths, a surrogate tag, or the whole distribution; the provider marks matching objects stale and the next request refetches from the origin. Propagation across an edge network usually takes seconds but is not instantaneous or ordered, so two nodes can briefly disagree. Soft purge is the gentler variant: objects are marked stale but still served while a fresh copy is fetched behind them, which avoids the load spike. The cache-busting route needs no coordination at all — a build step writes a content hash into each asset filename, the markup is updated to point at the new names, and the markup itself is served with no-cache so it is always revalidated with an ETag. Where you cannot rename, such as a PDF whose link is printed on paper, a purge plus a short max-age of 300 seconds is the workable compromise.

Real-World Example

An agency replaces a 2 MB price list at wrenfield-rates.99helpers.site after a mistake in the VAT column. Because 99helpers keeps version history, uploading the corrected file over the same name publishes it and clears the cached copies in one step, and the previous version stays available for rollback. Readers who had already downloaded the old PDF are beyond anyone's reach, which is why the agency also emailed the ones who mattered.

Common Mistakes

  • Purging and assuming it is over — a shared cache obeys immediately, while a browser holding a long max-age copy is never asked
  • Wiping the entire cache for a one-file change — the hit ratio drops to zero and the origin absorbs the whole of the next few minutes of traffic
  • Adding a query string such as ?v=2 to bust a cache — some intermediaries ignore the query when keying, so it works in your browser and not for everyone
  • Renaming assets but forgetting the markup that points at them is itself cached — if the HTML is stale, it still asks for the old filenames

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →