Origin Shield

A CDN with hundreds of edge locations has a structural problem the first time an object is requested: every location misses independently, and every location goes to origin. Request collapsing within a node reduces a million user requests to one request per node — and still leaves hundreds of origin requests for a single object.

An origin shield inserts a middle tier. Edge misses route through a small number of parent caches, which themselves collapse and cache. Origin then sees a handful of requests regardless of how many edges exist.

Why it matters

It changes what origin load is proportional to. Without a shield, origin load scales with the number of edge locations — which grows as the CDN expands, meaning improving your global footprint makes your origin problem worse. With a shield, origin load scales with the number of distinct objects being refreshed, which is a property of your content, not of your network.

That is the difference between an origin sized for a viral event and an origin that falls over during one.

Implementation patterns

• Request collapsing at every tier, not only at the edge. A shield without collapsing merely relocates the fan-in.
• Shield placement near origin, so the edge-to-shield hop is the long one and the shield-to-origin hop is short and cheap.
• A small number of shields, since the whole point is reducing fan-in — too many and the benefit disappears.
• Negative caching at the shield. Without it, requests for a nonexistent object bypass every layer and reach origin unimpeded, which turns a broken link or a scanning bot into an origin incident.
• Stale-while-revalidate throughout, so once populated, no user ever waits for a refresh and expiry never forms a stampede.
• Jittered TTLs, so replicas do not expire in unison.

Industry example

The viral-content case makes the arithmetic vivid. One asset becomes extremely popular within minutes. Every edge location either lacks it or sees it expire around the same time.

With per-node collapsing alone, a thousand edge nodes generate a thousand origin requests — better than a million, and still a burst the origin was never sized for. Add shielding and it becomes single digits. Add stale-while-revalidate and, after the first fetch, no user ever waits for a refresh. Add proactive warming for predictable events — a scheduled launch, a featured item, an expected news moment — and even the initial burst disappears.

Those four mechanisms together are why a modest origin can survive a global viral event, and why any one of them alone is insufficient.

The most valuable decision, though, sits upstream of all of it: make user-facing assets immutable and content-addressed, so changing an asset means publishing a new URL rather than invalidating an old one. Immutable objects can be cached effectively forever, reducing the whole problem to initial population.

Failure scenarios

• The shield becomes a bottleneck or a single point of failure — it needs redundancy and capacity of its own, and a bypass path for when it is unhealthy.
• No negative caching, so misses for nonexistent objects are unshielded.
• An incomplete cache key, which during a viral event either serves the wrong variant to millions or fragments the cache so nothing is hot. Quiet until it is not.
• Shield placed far from origin, adding latency to every miss without reducing the expensive hop.
• Personalised responses passing through, where a missing key dimension turns a caching bug into a data leak.

Trade-offs

A shield adds a hop on cache misses, which slightly increases miss latency, and adds a tier to operate, monitor and capacity-plan. For a small CDN footprint or an origin with ample headroom, it is unnecessary complexity.

It earns its place when the number of edge locations is large enough that fan-in alone threatens origin — which is precisely when the business is most exposed, since that is also when the content is most popular.

Interview question

"A single object goes viral and receives millions of requests in minutes across a global CDN. Walk me through caching, origin shielding, request collapsing, stale-while-revalidate and cache warming — and tell me which one you would build first if the events are always unpredictable."