CDN Production Engineering

Some CDNs support a mode where all responses are cached unless explicitly marked otherwise — powerful, but dangerous if origin routes don't set explicit Cache-Control headers.

A mid-tier cache sits between edge PoPs and the origin, so a miss at one edge doesn't always trigger a full origin trip — it can be satisfied by the tier cache instead, further reducing origin load.

public allows any cache (CDN, browser, intermediate proxy) to store the response. private restricts caching to the end-user's browser only — critical for personalized content that shouldn't sit in a shared CDN cache.

max-age applies to all caches including the browser. s-maxage applies specifically to shared caches (CDNs) and takes precedence over max-age there — letting you set a longer edge TTL than browser TTL.

no-cache allows caching but requires revalidation with the origin before serving (via ETag/Last-Modified). no-store forbids caching entirely, anywhere.

For hashed static assets (app.a1b2c3.js), set TTL to a year (max-age=31536000, immutable) — the filename itself changes on every deploy, so staleness is impossible.

A product listing or homepage might use a 10–60 second TTL — short enough that changes propagate quickly, long enough to absorb the vast majority of concurrent requests.

Most CDNs let you set a minimum or maximum TTL at the edge configuration level, overriding what the origin sends — useful as a safety net against a misconfigured origin sending max-age=0 everywhere.

Remove a single cached object across all edge locations — the most surgical option, but doesn't scale to bulk changes.

Tag related responses (e.g., all pages referencing a product) with a shared key at cache time, then purge everything under that key in one call — essential for content-managed sites where one change affects many cached pages.

Purge everything matching a path pattern (/blog/*) — powerful but slow to propagate and easy to overuse; treat as a last resort.

Strip tracking parameters (utm_source, fbclid) from the cache key so semantically identical requests share one cache entry instead of fragmenting into thousands of near-duplicate entries.

Only include a header in the cache key (via Vary) when the response genuinely differs by that header — every additional Vary dimension multiplies the number of cached variants.

Cache dynamic API or HTML responses for a very short window (1–30 seconds) — often short enough that users do not notice staleness, but long enough to absorb bursts of identical requests during traffic spikes.

Even when a response is not cacheable, many CDNs still terminate client TLS nearby, reuse warm connections to origin, route traffic over the provider's optimized backbone, and fail over between healthy origins or shield tiers. Dynamic traffic still benefits from the CDN even without an edge cache hit.

Some CDNs run small pieces of application logic directly at the edge (redirects, A/B test bucketing, request rewriting, authentication checks, even full server-rendered pages) — reducing origin round trips for logic that doesn't need the full origin stack.

Terminate client TLS at the edge and often re-encrypt to the origin, reducing user-to-edge handshake distance while centralizing certificate management and policy enforcement.

Filter malicious request patterns (SQLi, XSS, known bad bot signatures) at the edge, before they ever reach application servers.

Restrict access to protected content (paid media, private downloads) using time-limited signed URLs validated at the edge — no need to hit the origin to authorize every request.

Because anycast spreads traffic across every PoP globally, a volumetric attack gets naturally distributed across the entire network instead of concentrating on one target.

Apply per-IP or per-token request limits before traffic ever reaches the origin, blocking abusive clients at the network edge.

Serve CAPTCHAs or JS challenges to suspicious traffic patterns at the edge, filtering out automated attacks while letting legitimate users through unaffected.

The headline metric — percentage of requests served from cache. A sudden drop usually points to a TTL, cache-key, or content-type regression.

How many requests actually reach the origin per second — the metric that most directly reflects the CDN's protective value.

Response time as measured at the edge, broken down by region — reveals whether specific PoPs or regions are underperforming.

Track 5xx rates separately at the edge vs the origin — a spike in edge-originated 5xx often points to a CDN configuration issue rather than an application bug.

Caching a response that varies by a header or parameter not included in the cache key — one malicious or malformed request gets cached and served to every subsequent user.

A popular object's TTL expires and many concurrent requests all trigger simultaneous origin fetches instead of one request populating the cache while others wait — mitigated by request collapsing.

A deploy ships new content but the CDN keeps serving the previous version until TTL expiry because invalidation wasn't triggered as part of the pipeline.

Caching a 500 or 502 response with a long TTL means users keep seeing the error long after the origin has recovered.

Most CDNs expose a response header (X-Cache: HIT/MISS, CF-Cache-Status, etc.) — always check this first before assuming a caching bug.

Use browser devtools or curl -I to inspect the real headers the origin sent — the CDN can only obey what it's told.

A caching issue can be region-specific — one PoP might hold a stale or corrupted cache entry while others are fine. Use a multi-region testing tool rather than trusting a single request from one location.

Add a cache-busting query parameter or use an explicit bypass header/path to rule the CDN in or out — if the bug reproduces with cache bypassed, it's an origin issue, not a CDN caching issue.