Cache Purging Without Downtime: A Safer Invalidation Workflow

When a price, product image, campaign page, or JavaScript bundle changes, users need the right version quickly. The risky response is to empty the entire CDN cache and hope the origin can absorb the refill. That creates a cold-cache event precisely when a release, promotion, or incident is already demanding attention.

Safe invalidation is not a single button. It is a sequence: publish a known-good replacement, invalidate the smallest affected set, verify from representative locations, and keep a reversible version available. The rules below apply across CDN products, including Cloudflare and Fastly, even though their dashboards and APIs use different names.

Start with the cache contract

Before touching a purge control, document what each response means and how it becomes fresh. The HTTP standard distinguishes a fresh response, which can be reused without contacting the origin, from a stale response that needs validation or an explicit stale-serving policy. Cache-Control, ETag, Last-Modified, and Vary form the contract between your origin and shared caches. RFC 9111 is the authoritative reference.

Classify the object first:

• Immutable assets: hashed CSS, JavaScript, fonts, and images can use long edge lifetimes because a new filename represents a new version.
• Revalidated content: editorial pages and catalogue data may use a moderate shared-cache lifetime with validators such as ETag.
• Sensitive or personalized responses: account pages, carts, checkout, and responses containing private data should normally be private or uncacheable.

This classification prevents a content update from becoming a security incident. A purge is not a substitute for correct cacheability, and no-cache means revalidate before reuse, not necessarily do not store.

A safer invalidation workflow

1. Identify the complete change set

Write down the canonical URLs, hosts, cache-key dimensions, and related objects affected by the release. A product edit may touch the product page, category listings, search results, recommendations, sitemap, and a resized image family. Include query-string and language variants if they are part of the cache key.

Do not guess from the browser address bar alone. Inspect response headers and the CDN configuration to learn whether cookies, device signals, country, Accept, or Accept-Language create separate variants. If the response is selected by Accept, the origin must expose the appropriate Vary behavior so a shared cache does not serve AVIF to a client that cannot decode it.

2. Publish the replacement before invalidating

Make the new object available at the origin and test it directly, preferably through a staging hostname or an origin override. For a release, upload assets first, deploy the application that can reference them, then switch the HTML or manifest to the new version. Keep the previous asset and application version available until verification is complete.

This ordering avoids a purge exposing a missing object. It also makes rollback a deployment action rather than a race against an empty cache.

3. Choose the smallest invalidation scope

Use a single-URL purge for a single stable URL. Use content tags or surrogate keys when one logical item appears at many URLs. Use a path prefix or hostname only when every object in that scope is known to be affected. Treat a full-zone purge as an incident tool, not a release routine.

Cloudflare documents single-file purging as the recommended default and also supports tags, prefixes, hostnames, and purge-everything. Fastly supports URL purges and surrogate-key purges; its soft purge can mark objects stale while retaining them temporarily. Those are provider-specific controls, so confirm exact limits and semantics in the account documentation before automating them.

4. Prefer soft transitions where freshness allows

For non-critical editorial content, stale-while-revalidate can let the edge serve a recently expired object while it fetches a fresh version in the background. stale-if-error can preserve a usable response when the origin is unavailable. These directives are defined in RFC 5861, but a business rule still decides whether a slightly old price or availability message is acceptable. Never use stale serving to justify caching private or security-sensitive data.

5. Rate-limit and observe purge jobs

Treat invalidation as production traffic. Queue requests, deduplicate URLs, retry only documented transient failures, and record the change ID, operator, scope, provider response, and timestamp. Avoid launching thousands of independent calls when tags or a bounded batch can express the same change. Watch origin requests, error rate, latency, cache-hit ratio, and the age of the newest response while the cache refills.

Verify from the edge, not just from one browser

Verification should answer four questions:

1. Does the new content exist at the origin and through the production hostname?
2. Did the purge target every relevant cache-key variant?
3. Are edge responses returning the expected version marker, ETag, or deployment ID?
4. Did origin load and error rates remain within the release budget?

Use curl -I or a full request from several regions and both cold and warm sessions. Inspect provider cache-status headers, Age, Date, ETag, and Vary. A first request showing MISS is not a failure; it proves the request reached the refill path. A later request should become a HIT with the new version. Check a real browser too, because the browser cache, service worker, and HTML cache are separate from the CDN cache.

For ecommerce, verify the business behavior as well as the bytes: product price, stock state, promotional banner, cart, and checkout. A page can look new while an API response or image variant remains old.

Rollback without a second outage

If the new object is malformed or increases errors, stop the rollout and restore the previous application or manifest version. If the prior assets still have immutable URLs, the old page can reference them immediately. Purge only the bad stable URLs or tags, then warm the known-good response from controlled probes. If the purge itself was too broad, throttle traffic or temporarily serve a safe stale response while the cache repopulates, provided that policy is safe for the content.

Keep rollback credentials and the invalidation runbook available to the person on call. A rollback that depends on finding an undocumented dashboard control during an incident is not a rollback plan.

Common mistakes

• Purging everything because one URL was wrong, causing a global origin surge.
• Updating the origin after purging, leaving an empty cache to fetch the old or incomplete release.
• Forgetting browser caches, service workers, image variants, or a second CDN in the delivery path.
• Purging the URL but not the cache key dimensions created by cookies, language, geography, or Accept.
• Caching authenticated or personalized responses because a generic rule matched their file extension.
• Using short TTLs everywhere instead of long-lived versioned assets and targeted purges.
• Treating a provider's success response as proof that every edge and browser has refreshed.

For the broader delivery model, read Optimi's managed CDN guide. Image variants and cache keys are also covered in the adaptive image guide, while static vs dynamic content explains which responses should be cacheable. For a resilience view, see how to make a website resilient in 2026.

There are only two hard things in Computer Science: cache invalidation and naming things.