Soft Purge vs Hard Purge: Choosing How to Invalidate CDN Content

This comparison sits within Cache Invalidation Patterns, part of Advanced Caching Strategies & CDN Architecture. When content changes, the CDN must stop serving the old version. A hard purge deletes the object from cache: the next request is a full miss that waits for the origin. A soft purge (Fastly's term; other CDNs have equivalents such as "invalidate as stale" or revalidation-forcing purges) marks the object stale instead: if stale-while-revalidate or stale-if-error allow, the CDN can still serve it while fetching a fresh copy in the background.

The difference matters most at scale. Purging a tag that covers thousands of pages — a site-wide header change, a price update across a category — with a hard purge sends every subsequent request for those pages to the origin until each is refilled. If the origin is slow or struggling, that purge can trigger an outage. A soft purge spreads the refresh over background requests, keeps TTFB at cache speed, and leaves stale content available if the origin fails.

Rapid Diagnosis

• Check post-purge origin traffic. Graph origin requests around large purges; tall spikes indicate hard purges of popular content.
• Check TTFB after deploys. If TTFB p75 jumps for minutes after each deploy's purge, users are paying for refills.
• Check freshness requirements. Some content must never be served stale after a change (legal takedowns, price errors); other content can tolerate seconds of staleness.
• Check CDN capabilities. Not all CDNs offer soft purge; some emulate it via short revalidation.

Root Cause Analysis

1. Hard purges of broad tags. A tag shared by many pages (a header fragment, a category) deletes large swaths of cache at once.

2. Cold refill. Every deleted object needs a blocking origin fetch, concentrating load right after the purge.

3. Coupled with deploys. Purges on deploy coincide with new code warming up, making the origin slowest exactly when load is highest.

4. No stale safety net. Hard-purged objects cannot be served even under stale-if-error.

Step-by-Step Resolution

1. Classify content by staleness tolerance

Content that must disappear immediately (legal removals, security issues, wrong prices with legal implications): hard purge. Everything else — editorial updates, design changes, routine data refreshes: soft purge.

2. Make sure responses allow stale serving

Soft purges only help if cached responses carry stale-while-revalidate (and ideally stale-if-error) or the CDN-specific equivalent; otherwise a stale object is treated like an expired one and fetched synchronously.

Cache-Control: public, max-age=0, s-maxage=3600, stale-while-revalidate=600, stale-if-error=86400
Surrogate-Key: article-123 section-sport

(The trade-off: after a soft purge, some users can see the previous version for a few seconds while the background refresh completes.)

3. Use soft purge in publish and deploy pipelines

# Fastly: soft purge by surrogate key.
curl -sX POST "https://api.fastly.com/service/$SERVICE/purge/section-sport" \
  -H "Fastly-Key: $FASTLY_TOKEN" -H "Fastly-Soft-Purge: 1"
# trade-off: soft purge semantics differ between CDNs; on platforms without a
# native soft purge, a hard purge plus request collapsing and tiered caching is
# the closest alternative.

4. Reserve hard purge for emergencies

Keep a separate, clearly labelled hard-purge path for content that must vanish immediately, and use it deliberately.

Verification

After switching publish pipelines to soft purges, compare origin request rates and TTFB p75 in the minutes after purges with the previous behaviour. Spot-check that updated content appears within seconds (the background refresh) and that hard purges still remove content immediately when used.

Worked Example: Site-Wide Navigation Changes

A publisher tagged every page with nav because the navigation was rendered into each page. Changing a menu item hard-purged 180,000 pages; origin traffic spiked twentyfold and TTFB p75 rose above two seconds for several minutes. Switching to soft purges with a 10-minute SWR window kept TTFB at cache-hit levels throughout, and origin traffic rose only modestly as pages refreshed in the background. The team later moved the navigation to a separately cached fragment, which removed the need for site-wide purges altogether.

Reducing the Need for Broad Purges

The best purge is a narrow one. Content that appears on many pages — navigation, footers, promotional banners, related-article widgets — causes broad purges whenever it changes. Moving such shared elements into separately cached fragments (assembled at the edge or fetched on the client) means a navigation change purges one fragment instead of every page. Similarly, tagging pages precisely (only with the entities they actually display) keeps purges proportional to what changed. Soft purging softens the impact of broad purges; fragment architecture and precise tags make them rare.

Purge Hygiene in Pipelines

Treat purges as part of the release, with the same observability as the deploy itself. Log each purge with its tags, the triggering event (deploy, publish, manual) and its type (soft or hard). Rate-limit automated hard purges so a misconfigured job cannot clear the whole cache repeatedly. And run a post-purge check: fetch a sample of affected URLs after a short delay and confirm the new content is served — catching the silent failures (wrong tag, expired API token) that otherwise leave stale content live until someone notices.

Common Mistakes

• Soft purging responses without SWR. The stale object cannot be served, so behaviour is identical to a hard purge.
• Hard purging on every deploy. Deploys rarely require instant removal of all HTML; soft purge suffices.
• Overly broad tags. One tag on everything turns every change into a site-wide purge.
• Not monitoring post-purge load. Purge-induced spikes are invisible without origin metrics around purge events.

Edge Cases

CDNs without soft purge. Emulate it with short s-maxage plus SWR and rely on natural expiry for most updates, keeping hard purges for urgent changes.

Multi-layer caches. A soft purge at the CDN does not affect browser caches or your own reverse proxy; align layers.

Personalised content. Purges apply to shared caches; personal data should not be in them.

Purge rate limits. CDNs limit purge API calls; batch tags and avoid per-object purges in tight loops.

FAQ

Related

• Purging CDN cache by tag on deploy — tagging and purge pipelines.
• Choosing SWR windows for HTML and APIs — the windows soft purges rely on.
• Edge Side Includes vs client-side fragments — fragment architectures that narrow purges.