A cache purge is an explicit instruction to a cache, most often a CDN edge network, to remove or invalidate stored copies of content before their normal expiry, so that the next request is fetched fresh from the origin server. In content delivery, purging is the counterpart of caching: Cache-Control headers decide how long content may be reused, and a purge overrides that decision when content changes earlier than planned.
The term is used almost interchangeably with cache invalidation, although some platforms distinguish between deleting an object outright and merely marking it stale so it must be revalidated. Both serve the same goal: making sure visitors stop receiving outdated content within seconds of a change.
How a cache purge propagates through a CDN
A purge starts with a request to the CDN’s control plane, usually through an API call, a dashboard action or a deployment hook. The control plane identifies the affected objects and broadcasts the instruction to every point of presence, where each edge cache deletes or invalidates its local copy. Modern networks complete this global fan-out in seconds, while older systems could take minutes.
After the purge, the first request at each location becomes a cache miss. The edge forwards it to the origin, or to an origin shield in tiered caching, stores the fresh response and serves later requests from cache again. The purge therefore creates a short, predictable rise in origin traffic that scales with the number of locations and the popularity of the purged objects.
A purge acts only on caches the operator controls. Browser caches and intermediate proxies that already hold a copy keep it until their own expiry, which is why purging and header design must be planned together.
Purge methods and their scope
CDNs offer several ways to select what to purge, ranging from a single exact URL to the entire cache. The choice determines precision, speed and the load that follows on the origin.
| Method | What it targets | Precision | Origin load afterward |
|---|---|---|---|
| Single URL purge | One exact URL, including query string | Very high | Minimal |
| Prefix or wildcard purge | All URLs under a path such as /blog/ | Medium | Moderate |
| Tag or surrogate key purge | Every object labeled with a given tag | High, across many URLs | Proportional to tagged set |
| Hostname purge | All content for one hostname | Low | High |
| Purge everything | The whole cache of a zone or service | None | Very high, risk of overload |
Tag-based purging is the most powerful method for dynamic sites. The origin attaches a header such as Surrogate-Key or Cache-Tag listing identifiers like product-1234 and category-shoes. When a product changes, one API call purges every page that shows it, including listings and search pages, without the application needing to know their URLs.
Hard purge versus soft purge
Platforms differ in what happens to the purged object. A hard purge deletes it, so the edge has nothing to serve until the origin responds. A soft purge keeps the object but marks it stale, so the edge must revalidate it, yet may still serve the stale copy if the origin is slow or unavailable.
| Property | Hard purge | Soft purge |
|---|---|---|
| Effect on cached object | Deleted | Marked stale |
| Next request | Full fetch from origin | Conditional revalidation |
| Behavior when origin fails | Error returned | Stale copy may be served |
| Bandwidth on revalidation | Full object transferred | Often only a 304 response |
| Best for | Legal takedowns, leaked content | Routine content updates |
Soft purging works best together with `stale-while-revalidate` and `stale-if-error` directives, which let caches answer instantly while fetching the update in the background. The decisive rule is to use a hard purge only when stale content must never be served again.
Purging compared with other freshness strategies
Purging is one of several ways to keep cached content correct, and mature setups combine them. Short TTLs limit staleness without any purge, but lower the cache hit ratio. Versioned URLs make purges unnecessary for static assets because every change produces a new address.
| Strategy | How it works | Main trade-off |
|---|---|---|
| Event-driven purge | Purge when content changes | Requires integration with publishing |
| Short TTL | Cache expires after seconds or minutes | Lower hit ratio, more origin load |
| Versioned asset URLs | File name contains a content hash | Only suits static assets |
| Revalidation with ETags | Cache asks origin whether copy changed | Adds latency to each check |
| Long TTL with soft purge | Cache for days, invalidate on change | Depends on reliable purge calls |
For most sites, the strongest pattern is long TTLs plus event-driven tag purges for HTML and API responses, and immutable hashed file names for scripts, stylesheets and images.
Common mistakes and operational risks
The most damaging mistake is the habitual purge everything. Emptying a whole cache sends every request to the origin at once, a thundering herd that can overload servers precisely when a release is being deployed. Origin shields and request collapsing soften this effect, but do not remove it.
- Cache key mismatch: purging
/pagedoes not remove/page?utm_source=xif query strings are part of the cache key. - Forgotten variants: compressed, device-specific or language variants may be stored separately.
- Purge before publish: purging before the origin serves the new version simply recaches the old content.
- API rate limits: purging thousands of single URLs in a loop can hit provider limits; tags scale better.
- Assuming browsers are cleared: visitors may still see old content cached locally.
Put simply
Websites keep copies of their pages in servers around the world so visitors get them quickly. This is a little like a chain of shops keeping a product in stock locally. A cache purge is the recall notice. It tells every shop to throw out the old copy and fetch the new one.
Without a purge, visitors could keep seeing an old price or a corrected mistake for hours. With a purge, the update reaches everyone within seconds.
In practice
An online electronics shop caches product and category pages at its CDN for 24 hours, which keeps the cache hit ratio above 90 percent during sales. Each page carries tags such as product-5521 and category-laptops in a cache tag header.
During a promotion, a pricing error lists a laptop far below cost. The merchandising team corrects the price in the shop system, and a publishing hook sends a soft purge for the tag `product-5521`. Within a few seconds, the product page, two category pages and the home page carousel are all invalidated across every location.
The next visitors trigger revalidation at the origin and receive the corrected price, while the rest of the catalog remains cached. The origin load barely changes, and the error is visible for less than a minute instead of a full day.