Day-to-day CDN scenarios

Most CDN performance problems happen during predictable high-stakes moments: a product launch, a flash sale, a deployment push, a social media viral moment. This page maps those moments to concrete MaxoPerf test patterns — how to set up the test, what to look for, and what the results tell you 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 entirely 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 was updated overnight for the sale), the first wave of traffic will generate a thundering herd to origin.

How to test in MaxoPerf:

1. Run a cache-hit test the night before the sale to confirm cache TTLs and warm the CDN.
2. Simulate the surge pattern: a near-instant ramp to peak VU count (spike test profile) immediately after a cache warm phase.
3. Assert that X-Cache: HIT is returned on all asset requests throughout the surge.
4. 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 cache across all edge nodes simultaneously. Origin receives direct requests from every edge PoP for the new files until the cache re-warms. Origin must handle this surge; it must also not serve the old file version from cache during the re-warm window.

How to test in MaxoPerf:

1. Run at production load rate before the deployment to establish a baseline.
2. Trigger the deployment purge.
3. Continue the load test through the purge and re-warm window.
4. Assert that the new version is being served (via response body checks or version headers) and that TTFB recovers 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 temporary TTFB spike immediately after purge, followed by recovery within 3 minutes. No sustained 5xx errors on origin.

Scenario 3 — purge storm (mass invalidation)

Situation: A content platform’s editorial system triggers a mass purge of 50,000 article pages simultaneously due to a global template change.

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

How to test in MaxoPerf:

1. Identify a representative sample of high-traffic URLs from your CDN logs (50–200 URLs).
2. Write a MaxoPerf test hitting that URL sample at 2–3× production rate (simulating the burst immediately after purge).
3. Run the test cold (all URLs uncached) to simulate immediate post-purge conditions.
4. Monitor origin error rate and TTFB. If origin errors appear, the origin needs more capacity, rate limiting, or origin shield must be enabled.

• 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, each served at multiple resolutions via a CDN image-transformation service. 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 subsequent requests from cache. If the same image is requested in a dozen different sizes, only the first of each size is transformed and cached; the rest are served instantly. But if image URLs are parameterised uniquely per user (e.g. tracking IDs in the URL), each request is a cache miss and a transformation.

How to test in MaxoPerf:

1. List the 500 image URLs in a CSV data file.
2. Use MaxoPerf’s CSV data entity to drive the test.
3. Run warm and cold comparison: first pass (cold, transform happens), second pass (warm, cached response served).
4. 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 subsequent requests. Transformation service errors are zero.

Scenario 5 — regional CDN failover

Situation: A CDN provider announces planned maintenance for their Asia Pacific PoPs. Traffic is expected to reroute to the nearest US West region. You need to verify user experience in the APAC region does not become unacceptable.

Why CDN testing matters: Failover routing increases geographic distance between end users and the serving edge. TTFB in APAC may go from 20 ms to 120 ms if traffic routes through US West. This may be acceptable for a maintenance window, but must be measured and communicated.

How to test in MaxoPerf:

1. Set up a multi-region test with an APAC location and a primary location.
2. Run baseline: both regions normal.
3. Simulate failover by modifying your DNS/CDN routing rules to redirect APAC traffic to US West (in a test distribution, not production).
4. 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 increases during simulated failover but stays within the agreed SLA. No errors. Traffic automatically routes back to APAC PoPs when routing is restored, 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 to follow for all of these scenarios.