Day-to-day CDN scenarios

Most CDN performance problems happen at predictable high-stakes moments: a product launch, a flash sale, a deployment, a post that goes viral. This page maps each moment to a MaxoPerf test pattern. For each one you get the test setup, what to look for, and what the results say about CDN readiness.

Scenario 1: flash-sale asset surge

Situation: An e-commerce site announces a 24-hour flash sale. Marketing sends an email to 2 million subscribers at 09:00. Within the first minute, traffic jumps from 1,000 requests/second to 80,000 requests/second. Almost all of it goes to the product pages, promo banner images, and JS bundle.

Why CDN testing matters: The CDN must absorb the surge without passing it to origin. If the cache is cold at 09:00 (because content changed overnight for the sale), the first wave of traffic sends a thundering herd to origin.

How to test in MaxoPerf:

Run a cache-hit test the night before the sale to confirm cache TTLs and warm the CDN.
Simulate the surge: a near-instant ramp to peak VU count (spike test profile) right after a cache warm phase.
Assert that every asset request returns X-Cache: HIT for the whole surge.
Set failure criteria: p95 TTFB < 50 ms, error rate < 0.5 %.

execution:
  # 5-minute cache warm phase
  - concurrency: 20
    hold-for: 5m
    scenario: cdn-warm

  # Flash-sale surge — instant ramp to peak
  - concurrency: 2000
    ramp-up: 30s
    hold-for: 10m
    scenario: cdn-surge

scenarios:
  cdn-warm:
    default-address: https://cdn.example.com
    requests:
      - url: /static/sale-banner.webp
        label: sale-banner
      - url: /static/app.js
        label: app-js
      - url: /static/styles.css
        label: styles

  cdn-surge:
    default-address: https://cdn.example.com
    requests:
      - url: /static/sale-banner.webp
        label: sale-banner
        assert:
          - contains:
              subject: headers
              value: 'X-Cache: HIT'
      - url: /static/app.js
        label: app-js
        assert:
          - contains:
              subject: headers
              value: 'X-Cache: HIT'

What success looks like: TTFB stays flat through the VU ramp. Assertion failures near zero. No origin errors in the Log tab.

Scenario 2: new static deployment

Situation: Engineering ships a new version of the JS bundle and CSS files. The deployment pipeline purges the old cached versions. Users must receive the new files.

Why CDN testing matters: The purge invalidates the cache on all edge nodes at once. Until the cache re-warms, every edge PoP requests the new files directly from origin. Origin must handle this surge, and the CDN must not serve the old file version from cache during the re-warm window.

How to test in MaxoPerf:

Run at production load rate before the deployment to establish a baseline.
Trigger the deployment purge.
Continue the load test through the purge and re-warm window.
Assert that the CDN serves the new version (with response body checks or version headers) and that TTFB returns to baseline within the target re-warm time.

Set a deadline: “the cache must be fully warm within 3 minutes of deployment.” Measure this from the MaxoPerf run timeline.
Review Cache invalidation and purge testing for the full purge pattern.

What success looks like: A short TTFB spike right after the purge, then recovery within 3 minutes. No sustained 5xx errors on origin.

Scenario 3: purge storm (mass invalidation)

Situation: A global template change makes a content platform’s editorial system purge 50,000 article pages at once.

Why CDN testing matters: Mass purge is the highest-risk CDN operation. Every edge node drops its cached copy of every purged URL at the same moment. The origin burst can be 100× normal.

How to test in MaxoPerf:

Identify a representative sample of high-traffic URLs from your CDN logs (50–200 URLs).
Write a MaxoPerf test that hits that URL sample at 2–3× production rate (the burst right after the purge).
Run the test cold (all URLs uncached) to match conditions right after the purge.
Watch origin error rate and TTFB. If origin errors appear, the origin needs more capacity or rate limiting, or you need to enable origin shield.

Review Origin shield and offload testing. Shield is the best mitigation for purge storms.

What success looks like: Origin handles the cold-cache burst with < 1 % error rate. TTFB returns to cached baseline within 5 minutes.

Scenario 4: image-heavy marketing campaign

Situation: A retailer launches a campaign with 500 high-resolution product images. A CDN image-transformation service serves each one at multiple resolutions. Images are large (200 KB–2 MB each).

Why CDN testing matters: Image-transformation CDNs (Cloudinary, imgix, AWS CloudFront with Lambda@Edge) often cache the first transformation and serve later requests from cache. If clients request the same image in a dozen sizes, the service transforms and caches only the first request for each size. It serves the rest instantly. If image URLs carry a unique parameter per user (e.g. tracking IDs in the URL), every request is a cache miss and a transformation.

How to test in MaxoPerf:

List the 500 image URLs in a CSV data file.
Use MaxoPerf’s CSV data entity to drive the test.
Compare warm and cold: the first pass is cold (the transform runs), the second is warm (the cache serves the response).
Label requests by resolution variant to see which sizes have the best hit ratio.

scenarios:
  image-campaign:
    default-address: https://cdn.example.com
    data-sources:
      - path: images.csv
        variable-names: image_path
    requests:
      - label: campaign-image
        url: /cdn-cgi/image/width=800,format=webp/${image_path}
        method: GET
        assert:
          - equals:
              subject: http-code
              value: '200'

What success looks like: After the first pass, p95 TTFB drops to < 50 ms for later requests. The transformation service returns zero errors.

Scenario 5: regional CDN failover

Situation: A CDN provider announces planned maintenance for their Asia Pacific PoPs. The provider expects traffic to reroute to the nearest US West region. You need to confirm that the user experience in APAC stays acceptable.

Why CDN testing matters: Failover routing puts the serving edge farther from end users. TTFB in APAC may go from 20 ms to 120 ms if traffic routes through US West. That may be acceptable for a maintenance window, but you need to measure it and tell people.

How to test in MaxoPerf:

Set up a multi-region test with an APAC location and a primary location.
Run baseline: both regions normal.
Simulate failover by modifying your DNS/CDN routing rules to redirect APAC traffic to US West (in a test distribution, not production).
Re-run the multi-region test. Compare per-region TTFB before and after the routing change.

Set failure criteria: “TTFB in APAC must remain below 300 ms during maintenance.”

What success looks like: TTFB in APAC rises during the simulated failover but stays within the agreed SLA. No errors. Once routing is back to normal, traffic returns to APAC PoPs on its own and TTFB recovers.

Scenario quick-reference

Scenario	Key test type	Critical assertions	Failure signal
Flash-sale surge	Spike + warm cache	`X-Cache: HIT`, p95 TTFB < 50 ms	TTFB spike during surge
New static deployment	Load + purge + re-warm	New asset version served, TTFB recovers in 3 min	Origin errors, slow re-warm
Purge storm	Cold-cache load	Origin error rate < 1 %	5xx errors from origin
Image campaign	Multi-URL data-driven	p95 TTFB < 50 ms after warm	TTFB > 200 ms sustained
Regional failover	Multi-region load	APAC TTFB < 300 ms in failover mode	TTFB breach in failover region

Where to go next

Cache hit/miss testing: validate cache state for scenarios 1, 2, and 4.
Cache invalidation and purge testing: the full purge test pattern for scenarios 2 and 3.
Origin shield and offload testing: mitigation for scenarios 3 and 4.
Multi-region edge performance: how to run scenario 5 from multiple geographic locations.
CDN testing do and don’t: rules for all of these scenarios.