Cache Invalidation
How Cache Invalidation Keeps Copies Current
Cache invalidation is the process of marking stored copies as out of date, so that the next request fetches fresh content. A cache keeps copies of pages, images and API responses so it does not have to rebuild them each time. When the source changes, the stored copy becomes wrong, and something must signal that it should be replaced.
Software engineers often describe cache invalidation as one of the hardest problems in the field. The difficulty comes from the number of places copies can live. Browsers, CDN edge servers, reverse proxies and server caches each keep their own copies, and each may expire at a different time.
Common Invalidation Strategies
- Time-based expiry (TTL). Each copy has a time to live. When it runs out, the next request fetches a new copy. This is simple, but a copy can stay wrong until its time is up.
- Event-based invalidation. When content changes, the system removes the affected copies at once. This is accurate, but it needs a reliable signal from the application.
- Cache tags. Each cached item carries labels, such as a product ID. Changing that product clears every copy with that label and leaves unrelated pages alone.
- Versioned addresses. The address of a file changes whenever its content changes, so old copies are never requested again. This is the basis of cache busting.
The right choice depends on how often content changes and how costly a stale copy is. Short expiry times limit the damage of an error, but they send more requests to the origin.
Example: A Price Change During a Sale
A store lowers the price of a jacket at noon. The product page is cached on a CDN for one hour and in visitors' browsers for thirty minutes. Without invalidation, a customer who visited at 11:50 may still see the old price at 12:20 and be surprised at checkout.
The store can reduce this risk by purging the product page at the CDN when the price changes. Browser copies still expire on their own timer, so short cache lifetimes for pages that change often narrow the window of error.
Frequently asked questions
Is a short cache time better than purging manually?
Most sites use both. Short expiry times limit how long a mistake can last, while purges clear copies right after an important change. Purging too often reduces the benefit of caching, so the right balance depends on how often content changes. Pages that rarely change can safely use longer expiry times. Expiry is set with Cache-Control headers.
Why does my site still show an old version after I change it?
A copy is probably held by a layer you did not clear. Browsers, CDN edge servers, page caches and reverse proxies each keep their own copies and may expire them on different schedules. Clearing one layer does not clear the others. Waiting for expiry, or purging each layer in turn, resolves the problem.