CDN & Edge Caching

Two caches do the same five jobs and ship opposite defaults for the one that decides whether your origin survives a cache fill — which is why 'the CDN absorbs the miss' is true in front of one and false in front of the other, with no TTL you can change to fix it. Varnish coalesces without being asked: a request that arrives while another is already fetching the same key is parked on that object's waiting list rather than sent anywhere, so a thousand simultaneous misses become one backend fetch, and the parked requests are released onto the new object when it lands. nginx merges proxy_cache_lock to zero, so each concurrent miss is its own upstream request and the number reaching the origin is the miss rate times how long a fetch takes — by Little's law, hundreds of simultaneous fills of one object at a load where the hit ratio in the logs has not moved at all, because a ratio describes steady state and a collapse happens at the instant of a fill. Turning the lock on bounds the herd rather than removing it: its timeout and its age both default to five seconds, after which the waiting request goes upstream anyway. Origin fan-in is therefore three different numbers for the same traffic, settled by two switches people treat as one — one fetch per key when coalescing and a shield are both present, one fetch per PoP when coalescing is on and there is no shield, and the whole concurrent miss count when coalescing is off, where a shield collapses nothing because the shield tier has the same default. Then the key, which is not the URL: the default hash is VCL shipped inside the binary and it hashes the URL and the Host header, falling back to the server's address when no Host is present, so a second hostname on one origin starts cold. Vary multiplies rather than adds — each distinct combination of varied values is matched against a stored object's own vary string, every variant needs its own origin fetch to exist, and 'gzip, br' and 'br, gzip' are two objects — which is why Cloudflare's runtime refuses to implement ignoring Vary at all, saying in its own header that it is easy to blow up your cache keys, and refuses to ignore the query string too. Stale-while-revalidate is a condition, not a promise: both grace exits test that an expired copy still exists, and with keep at zero the object is gone at ttl plus grace, so a burst arriving after a quiet period pays the full fetch however generous the window — grace decides who waits on a revalidation, not whether anyone waits at all. Invalidation is the other inversion: a purge is legal only where the request has already resolved its object, which is exactly why it is keyed and costs the same at ten million objects, while a ban deletes nothing and is instead evaluated against every object on the hit path until a lurker paced at a thousand objects per ten milliseconds retires it, so tag semantics scale only when a surrogate-key index makes them keyed — and that index is not in core Varnish. Move logic to the edge and you move it inside a budget: every outbound call passes a subrequest gate that throws once the allowance is spent, and an isolate can be condemned for exceeding its limits. Change the arrival rate, hit ratio, TTL, varied-header count, grace window, origin fetch time, PoP count, shield, edge compute and coalescing behaviour, and watch the server-computed cascade across all five layers — the lookup ladder with its five exits rather than two, cache keys, purging strategies, edge compute and the origin shield. Validated against Varnish varnish-8.0.0 source (HSH_Lookup, the waiting list, the grace gate, VRT_purge, BAN_CheckObject, VRY_Match, vcl_builtin_hash and the pinned parameter defaults), nginx release-1.30.5 (proxy_cache_lock, its timeout and age, proxy_cache_use_stale and proxy_cache_background_update) and workerd v1.20260930.1 — the open-source Workers runtime, which is not the Cloudflare production edge.

• ✓All current + future modules
• ✓Full kata library
• ✓Progress dashboard + weak area analysis

Cancel anytime. Billed annually.