Cache invalidation and purge testing

Cache invalidation is one of the two famously hard problems in computer science, and in CDN operations it is one of the highest-risk routine activities. When you purge a cached resource, every edge node that held that object discards it. The next request to each edge becomes a cache miss and hits your origin directly. If your site serves high traffic and you purge a widely-cached asset during peak hours, the resulting origin surge — the “thundering herd” — can take your origin down.

CDN purge testing validates three things: (1) that purges actually work — stale content is gone, (2) that origin can absorb the post-purge traffic spike without failing, and (3) that the cache warms back up within an acceptable time window.

Before you start

• Have a test CDN environment or a low-traffic asset URL available. Purge testing requires you to issue actual purge API calls, which will temporarily increase origin traffic. Do not purge production hot-path assets during peak hours without a tested runbook.
• Know your CDN provider’s purge API. CloudFront, Fastly, Cloudflare, and Akamai each have different purge mechanisms (API calls, URL-based purge, tag-based purge). The MaxoPerf test itself is a load test — the purge trigger is external to MaxoPerf.
• Understand your origin’s baseline capacity from previous load tests so you know when a post-purge spike constitutes a real risk.

Understanding the thundering herd

The thundering herd problem after a CDN purge works like this:

1. You purge /static/app.js across all edge nodes simultaneously.
2. Every edge node marks the cached object as invalid.
3. The next request to each of your edge nodes (potentially hundreds of them globally) results in a cache miss and a synchronous request to your origin.
4. If you serve 10,000 requests/second globally across 200 edge nodes, those 200 simultaneous origin fetches arrive within milliseconds of each other.
5. Your origin must serve those 200 fetches before any edge node can re-cache the response and begin serving subsequent requests from cache again.

The severity depends on:

• Asset popularity — a home-page bundle touched by every request is far riskier to purge than a rarely-used static resource.
• TTL — a 24-hour TTL means the asset has been cached across many more edge nodes than a 5-minute TTL. Shorter TTLs reduce thundering-herd risk.
• Origin cache — if your origin has an in-memory or Redis-backed application cache, the first 200 fetches may still be served quickly.
• CDN origin shield — a CDN with an origin shield tier collapses all edge misses to a single request to the shield, which then fetches from origin once. See Origin shield and offload testing.

Test pattern 1 — measure post-purge origin impact

This pattern simulates realistic sustained traffic, triggers a purge, and measures how long the origin spike lasts.

Step 1: establish a warm-cache baseline

Run a load test at your production traffic rate for 5 minutes to warm the cache. Confirm cache hit ratio is above your target (typically 80–95 % for static assets). Record baseline p95 TTFB.

Step 2: trigger the purge externally

Issue the purge via your CDN provider’s API. This is done outside MaxoPerf:

# CloudFront example: invalidate a path
aws cloudfront create-invalidation \
  --distribution-id E1234ABCDEF \
  --paths "/static/app.js"

# Fastly example: purge a URL
curl -X PURGE https://your-cdn.example.com/static/app.js \
  -H "Fastly-Key: ${FASTLY_API_KEY}"

# Cloudflare example: purge by URL
curl -X POST "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/purge_cache" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"files":["https://your-cdn.example.com/static/app.js"]}'

Step 3: continue the MaxoPerf load test through the purge

Keep the MaxoPerf run active through the purge event. The run overview will show TTFB jumping at the moment of the purge as edge nodes stop serving from cache and begin fetching from origin.

Step 4: measure recovery time

Observe how long it takes for TTFB to return to baseline levels. This is your cache re-warm time — the window during which your origin is under elevated load and users are experiencing degraded performance.

Caution

If your origin cannot serve the post-purge burst (errors appear in the Log tab, or TTFB does not recover within your SLA window), reduce the scope of future purges (use tag-based or surrogate-key purge rather than wildcard purges) and ensure origin shield is enabled.

Test pattern 2 — staleness window validation

This pattern verifies that cached content is stale for at most the expected time after a content update, and that users do not see outdated responses for longer than acceptable.

The Taurus test asserts that a Cache-Control: max-age header value does not exceed your maximum acceptable staleness window:

execution:
  - concurrency: 5
    hold-for: 2m
    scenario: staleness-check

scenarios:
  staleness-check:
    default-address: https://cdn.example.com
    requests:
      - label: check-max-age
        url: /v1/catalog/featured-items
        method: GET
        assert:
          - equals:
              subject: http-code
              value: '200'
          - contains:
              subject: headers
              value: 'Cache-Control'
          - not-contains:
              subject: headers
              value: 'no-cache'        # this endpoint must be cached

After the test, inspect the Cache-Control: max-age value in the response headers against your freshness requirements. A max-age that is too long means stale data is served to users for too long after a content update.

Test pattern 3 — purge storm simulation

A purge storm happens when a large batch purge (e.g. deploying a new version of your entire static asset bundle) invalidates many objects simultaneously. This is the highest-risk purge scenario.

To simulate and measure:

1. Identify the set of assets affected by a typical deployment purge. List them in a CSV file.
2. Write a Taurus or k6 test that sends concurrent requests for all of those asset URLs immediately after the purge.
3. Run the load test at production traffic rate. Time the test to start immediately after your batch purge completes.
4. Monitor origin load during the re-warm window using your origin’s own observability (not just MaxoPerf). Origin errors or slow responses surface in the MaxoPerf Log tab as 5xx responses.

Note

Origin shield significantly reduces purge storm severity by collapsing parallel edge requests to a single origin fetch. If you are experiencing origin stress after purges, enabling or correctly configuring origin shield is the most impactful remediation. See Origin shield and offload testing.

How to read purge test results in MaxoPerf

When you run a load test through a purge event, look for:

Signal	What it means
Sudden TTFB spike in the run overview	Purge took effect — edge nodes are now fetching from origin.
TTFB returning to baseline within minutes	Cache is re-warming normally. The spike duration is your risk window.
5xx errors in the Log tab immediately after purge	Origin could not handle the post-purge burst. Scale origin or enable origin shield.
TTFB does not recover after purge	The TTL is very short or Cache-Control: no-cache is being returned — responses are not being re-cached after origin fetch.
Assertion failures on X-Cache: HIT during recovery	Normal during the re-warm window. The assertion failure rate drops as the cache fills back up.

Do / don’t

Do:

• Test purge behaviour in a staging environment or against a low-traffic asset before purging production hot paths.
• Keep the MaxoPerf load test running through the purge event so the TTFB timeline captures the spike and recovery.
• Test both targeted purge (single URL) and batch purge (whole directory or tag) — they have very different origin impact profiles.
• Know your origin’s capacity limit before purge testing so you can define a safe stop condition.

Don’t:

• Trigger a purge test during peak production traffic hours without a rollback plan and monitoring eyes on the origin.
• Assume a successful purge means re-caching worked — verify with a follow-up cache hit assertion test.
• Use wildcard purge (/*) for purge testing in production without measuring origin impact first.

Where to go next

• Origin shield and offload testing — reduce purge storm risk with shield configuration.
• Cache hit/miss testing — verify the cache re-warms correctly after a purge.
• Cache key and Vary testing — understand how cache keys affect purge scope.
• Daily scenarios — the “purge storm” scenario in context.