Cache Invalidation

Cache invalidation is the process of marking cached copies as no longer valid so the next request fetches fresh data from the origin. It covers browser caches, CDN edges, reverse proxies, and application caches such as Redis.

Why it matters

Caching makes sites fast, but a cached copy knows nothing about changes behind it. If invalidation fails, users see old prices, old articles, or a broken page that you already fixed. If you invalidate too aggressively, you lose the speed and protection caching provides.

Example

Common approaches, roughly from simplest to most precise:

1. Time-based expiry: Cache-Control: max-age=300 lets copies live five minutes.
2. Versioned URLs: app.3f9a1c.js changes name when content changes, so old copies are simply never requested again (see cache busting).
3. Purge by URL or tag: call the CDN API to remove specific objects after publishing.
4. Revalidation: the cache asks the origin with If-None-Match and an ETag, receiving a cheap 304 if unchanged.

A purge often has to be repeated at several layers. Clearing the CDN does nothing about copies already stored in visitors' browsers.

Common mistakes

• Purging everything after each deploy, causing a cache stampede on the origin.
• Setting long max-age on HTML that cannot be versioned.
• Forgetting a layer, such as a proxy cache or service worker.
• Assuming a purge is instant everywhere; propagation can take seconds or longer.

Related

• Cache-Control
• Cache busting
• CDN
• Browser cache

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.