Cache Purging Strategies - CDN Cache Invalidation

By the end of this lesson, you will be able to...

• Trace what happens at the edge and origin after a CDN purge for a changed public page.

• Choose a purge handle and a hard or soft transition from the freshness requirement and expected refill pressure.

• Investigate stale survivors and origin spikes using purge scope, cache-status, propagation, and refill signals.

Idea in one sentence: A CDN purge is a distributed state change: it must select every unsafe copy, make the transition visible at the edge, and keep the refill wave from becoming an origin outage.

Core Insight

At 11:00, the shop replaces a misleading hero banner on its homepage. The page is public and cached at many edge locations. It has four representations: Spanish and English, each in desktop and mobile form.

The first model says: issue “purge /,” then the page is fixed. That works only if / identifies every stored representation and the origin can comfortably answer every miss that follows. Neither condition is automatic.

One edge may hold home|es|desktop; another may hold home|en|mobile. If the purge matches only a visible URL but the provider's effective key includes variants, some users may still see the old hero. If a broad purge removes every warm copy at once, the change can be correct while the origin is suddenly asked to render the homepage from many places at the same time.

Purging is therefore not a delete button after a deployment. It is an operational transition between an old cache population and a new one. The same plan needs to answer: which copies become unsafe, how will readers get a fresh representation, and how much concurrent refill can the origin absorb?

The Production Symptom: Old Banner Here, Origin Spike There

The on-call view shows two reports ten seconds after the content team publishes:

Madrid, es, desktop: new banner
Toronto, en, mobile: old banner

origin homepage renders: 4x normal

These observations are not contradictory. They point to two separate questions.

1. Scope: Did the purge target the cache entries that can serve the English/mobile representation?
2. Transition: Did removing or expiring copies cause a refill surge through many edges or request paths?

Do not start by assuming that the CDN is “slow.” First capture the request route, chosen cache key dimensions, cache status, purge identifier or tag, content version, and edge location. Those details let the team distinguish an incomplete purge from a completed purge followed by a weak refill design.

The Initial Model: One URL Is One Cached Object

For a small local cache, a key may look like one URL and deleting it may be enough. That model works while the URL is the complete identity of the response and one cache serves a modest number of readers.

At a CDN, a public page can vary by path, language, device policy, query handling, an edge-selected experiment bucket, or provider-specific cache configuration. The previous lesson made one such choice visible: an edge function can turn raw request data into a bounded public variant. That same choice changes which stored objects a purge must affect.

Two opposing mistakes follow:

• Too narrow: purge only /, leave an English/mobile or experiment variant serving old content.
• Too broad: purge the whole distribution for one banner change, erase unrelated warm copies, and multiply origin misses.

The better model is not “always purge by URL” or “always purge everything.” It is to give related responses an explicit invalidation handle, then choose the smallest handle that matches the freshness promise.

The Failure Mechanism: Scope Meets Refill

In plain English, a purge tells an edge that a stored representation may no longer be used under the old freshness rule. The exact behavior and vocabulary differ by CDN, so confirm the selected provider's semantics. In this lesson, use these teaching definitions:

• Hard purge: the selected object is no longer servable; the next request normally needs a fresh origin path.
• Soft purge: the selected object is marked stale; a platform may revalidate or refresh it under its stale-serving policy instead of forcing an immediate cold miss for every reader.

The technical names are purge scope, propagation, and refill control. Scope selects the representations. Propagation is the control-plane movement that tells edge locations about the change. Refill control limits duplicate work once readers need a new copy.

For the homepage, a content model can attach a stable tag such as homepage to every language/device representation:

home|es|desktop  -> tags: homepage, campaign:summer
home|es|mobile   -> tags: homepage, campaign:summer
home|en|desktop  -> tags: homepage, campaign:summer
home|en|mobile   -> tags: homepage, campaign:summer

A purge for homepage has a clearer intent than manually listing every variant, as long as the origin and edge configuration actually assign that tag to every representation. That “as long as” is the operational contract. A tag that is missing on one response is not a documentation problem; it is a stale-content path.

A Worked Trace: Correct the Banner Without Creating a Stampede

Suppose the homepage may be stale for at most five minutes ordinarily, but the misleading banner must be removed quickly. The team has an origin shield and request coalescing for a cache miss. The timestamps are illustrative.

With a hard purge, the edge may need a new full response before serving the next request. That can be appropriate when the old content must not be shown. It costs more immediate origin work. With a soft purge or stale-while-revalidate-like policy, the platform may make a more gradual transition, but that is suitable only when the remaining stale window is acceptable. Do not label a soft transition “instant removal” if the product requirement says the old banner is unsafe.

The trade-off is situated: hard removal is justified when the old response is unsafe to show, while a soft transition is justified only when a stated stale window is acceptable and origin stability matters. Neither choice is a universal default.

So far, we have separated two outcomes. A successful control-plane submission is not the same as every edge having applied the policy. And a correct invalidation at every edge is not the same as a stable data-plane refill. Both must be observed.

Mitigation and Prevention

Choose the strategy from the content shape:

For frequently updated static assets, versioned names are often simpler than invalidating a stable name. CloudFront likewise documents versioned filenames as an alternative to invalidation and notes that invalidating an edge file makes the next viewer request fetch the latest version from origin. AWS CloudFront documentation.

Prevention starts before the incident: document cache-key dimensions, add tags at render time, test an edge variant in staging, estimate the origin cost of a cold key, and record the purge request id with the release. A purge runbook should include a rollback or fallback decision, not only the API command.

Signals to Watch

During a purge, use evidence that maps to the mechanism:

• Scope correctness: sample every expected language/device/experiment variant and check its content version.
• Propagation: time from accepted purge request to edges reporting the new state; treat the provider's completion signal and actual reader probes as different evidence.
• Refill amplification: origin and shield fetches per cache key, miss concurrency, and request-coalescing effectiveness.
• User impact: stale-content reports, p95/p99 latency, error rate, and cache status by route.
• Blast radius: count of affected keys/bytes versus the intended content set.

These signals expose the two common failure mechanisms. Old content with normal origin load suggests a scope or propagation gap. Origin stress with correct new content suggests a refill or purge-blast-radius problem. Both can happen together.

Check: A tag purge reports success, Spanish desktop shows the new banner, but English mobile still shows the old one. Origin load is normal. What should the investigation test first?

Think first, then reveal.

Answer: Test scope before capacity. Compare the English/mobile cache key and its assigned tags with the purge target, then inspect that edge's propagation state and response version. Normal origin load makes a refill stampede less likely; the evidence points first to a missing variant handle or incomplete propagation.

Readiness Check: Plan a Product Recall Notice

The shop must show a recall notice on all product pages within a short window. Product pages vary by language and device, while images use versioned URLs. The origin can tolerate a 30% temporary increase in page renders but not a full global cold start.

Write the smallest safe plan. Specify the purge handle, whether the old page may be served during transition, one refill protection, and four observations required before declaring the change complete.

A good answer should mention:

• a product-page tag/key that covers all language and device variants, rather than a purge-all;
• a hard or soft transition chosen from the actual safety window, with no stale serving if the notice is legally required immediately;
• request coalescing, origin shielding, staged scope, or bounded warmup to protect the 30% headroom;
• response-version checks across variants, purge propagation, origin/shield render rate, cache status or miss concurrency, and user latency/error signals; and
• versioned image URLs as a separate asset strategy, not a reason to purge unrelated cache content.

Connections

The previous lesson showed that an edge function can create bounded cache variants. This lesson makes their lifecycle operational: a purge must match the variants that edge code actually produces. The next lesson optimizes the same transition with key shaping, shielding, compression, and evidence-driven measurement.

Resources

• [DOCS] Invalidate files to remove content — Focus: Compare invalidation with versioned file names and inspect the next-request-to-origin consequence.
• [DOCS] Cloudflare cache purge API — Focus: Compare broad and granular purge handles against the cache-key context they must cover.
• [DOCS] Fastly purging reference — Focus: Verify the provider's current hard/soft purge and surrogate-key semantics before operational use.
• [ARTICLE] HTTP caching — Focus: Revisit freshness and conditional validation so purge and revalidation form one policy.

Key Takeaways

• A purge is a distributed transition: scope, propagation, and refill behavior all determine whether it is safe.
• The correct purge handle represents the full cache population that can serve the changed content, including edge-created variants.
• Hard removal and soft/stale transitions trade immediate freshness against refill stability; choose from the user promise, not convenience.
• Versioned asset names avoid many invalidation problems, while stable dynamic pages need deliberate handles and observability.
• Measure content version by variant, purge propagation, miss concurrency, origin work, and tail latency before calling an invalidation complete.