An origin shield is a mid-tier cache that sits between edge locations and your origin. Instead of every edge going to origin on a miss, edges fill from the shield and the shield fills from origin once. On global adult traffic — where a viral title can be requested from every region at once — the shield is the difference between one origin fetch and hundreds. This page covers shield clusters, request collapsing, origin failover, and the pitfalls.
How shielding reduces origin load
Without a shield, a cold or purged object is fetched independently by each edge location, and the origin sees one request per location per object. With a shield, the topology becomes origin → shield → edges.
- Request collapsing merges concurrent misses for the same object at the shield into a single origin fetch. The first request fills; the rest wait for that fill instead of stampeding origin.
- Regional concentration means origin sees a small, stable set of shield addresses rather than a large, shifting set of edge addresses. Origin allow-lists and TLS sessions become simpler.
- Deeper retention at the shield absorbs the long tail that would otherwise be evicted at the edge.
Shield clusters and region choice
A shield cluster is a set of shield nodes that share cache state and act as one logical origin-facing cache. Choose the shield region deliberately:
- Put the shield near the origin when origin latency or egress cost dominates, so origin fills are short and cheap.
- Put the shield near the traffic when the same objects are requested repeatedly across nearby regions, so shield hit ratio is high.
- For global catalogues, a small number of shields (one per continent) usually beats one global shield, because a single shield adds latency for distant edges.
- Keep the shield inside the same access-control boundary as the origin; it should be the only thing allowed to talk to origin.
Origin groups: active and passive
An origin group pairs a primary origin with one or more backups. Two failover models:
| Model | Behaviour | Trade-off |
|---|---|---|
| Active/active | Health-checked origins both serve; traffic splits or fails over | Best availability; requires consistent content on both |
| Active/passive | Primary serves; backup takes over on failure | Simpler and cheaper; failover is a step change |
Health checks decide when to fail over. Tune them for the failure you actually care about: a fast check that flips on a single dropped response causes flapping, while a slow check leaves viewers on a dead origin. Prefer a short interval with a failure threshold over a single probe. The same rules apply at the shield as at the edge.
Shield-side mutations are cached downstream
Anything the shield does to a response is what edges receive and cache. This is powerful and dangerous:
- Header rewrites at the shield — adding
Cache-Control,CDN-Cache-Control, or CORS headers there — propagate to every edge and into the cache entry. Fix a header at the shield and you fix it everywhere; get it wrong and you poison the whole tier until purge. - Range and compression decisions made at the shield determine what edges can serve from cache. If the shield returns a full object where an edge expected a range, seek traffic degrades downstream.
- Redirects and error pages cached at the shield are served by every edge. Be explicit about which status codes are cacheable.
Treat the shield configuration as part of the origin contract, not an edge detail.
Avoiding stampedes
Stampedes happen when many requests miss the same object at once. The usual triggers are a viral spike, a cold regional cache, or a hard purge of a hot object.
- Rely on request collapsing rather than raising origin capacity to absorb the spike.
- Use soft invalidation for updates and takedowns so hot objects are marked stale and refilled by one request, not all of them. See Purge, invalidation, and prefetch.
- Pre-warm the hot set before a promotion so the spike lands on a warm cache.
- Add a small random jitter to origin revalidation timing so expiry does not align across the fleet.
Where AdultInfra fits
AdultInfra designs shield topology and origin failover around your origin cost and traffic geography, then verifies that range responses, headers, and failover behave correctly at the shield. Bring one hostname and the origin-egress or availability metric you want to improve and talk to us.