CDN Caching for Video: Cache Keys, Origin Shields, and TTLs
Why video CDN configuration differs from web asset caching, and the specific settings that decide your origin load and your bandwidth bill.
A CDN in front of a video origin is doing something quite different from a CDN in front of a website. The objects are large, immutable, requested in strict sequence, and overwhelmingly concentrated on a small fraction of the catalogue. Default configurations tuned for web assets handle this badly, and the symptoms (origin overload during live events, poor cache hit ratios, inexplicable bandwidth costs) trace back to a handful of specific settings.
The Two Object Types
Video delivery has exactly two kinds of cacheable object, and they need opposite treatment.
Media segments are immutable. Once written, seg-00042.m4s never changes. If its content changed, it would be a different segment with a different number. This means segments can be cached essentially forever (a TTL of a year is entirely reasonable) and the standard Cache-Control: public, max-age=31536000, immutable applies cleanly.
Manifests are mutable, and how mutable depends on the stream type. A VOD manifest is written once and never changes, so it can be cached as aggressively as segments. A live manifest changes every segment duration, because each new segment must be announced in it. That makes the live manifest the single hottest, least cacheable object in the entire system.
Getting this distinction wrong in either direction is costly. Short TTLs on segments destroy your hit ratio and hammer the origin. Long TTLs on live manifests freeze the stream: players keep receiving a stale playlist and stall at the end of the last segment they know about.
For live manifests, the TTL should be roughly half the target segment duration. Six-second segments suggest a two-to-three-second TTL. This lets the CDN absorb the bulk of manifest polling while keeping staleness below one segment.
Cache Keys
The cache key determines what counts as "the same object." The default on most CDNs includes the full URL with query string, and for video that default is usually wrong.
Video URLs frequently carry query parameters that have nothing to do with which bytes are being requested: session identifiers, authentication tokens, analytics parameters, player version strings. If those are in the cache key, every viewer creates their own private cache entry for content that is byte-identical across all of them. Hit ratio collapses toward zero and the origin serves every request.
The fix is to strip everything from the cache key that does not affect the response body. On most CDNs this is a whitelist: include only the path, and only those query parameters that genuinely select different content.
The complication is token-based authentication, where a signed token in the query string must be validated but must not be part of the key. Handle this with an edge function or the CDN's native token authentication feature: validate the token at the edge, then look up a normalized key. If your CDN cannot separate these two functions, moving tokens into a cookie or a path segment is usually simpler than fighting it.
Also worth normalizing: Vary headers. A Vary: User-Agent on video responses fragments the cache across every browser version in existence. Almost no video response legitimately needs it.
Origin Shield
An origin shield is an intermediate caching tier between the edge points of presence and your origin. Without it, every edge PoP that experiences a cache miss goes to origin independently.
The arithmetic matters at scale. With 100 edge locations and no shield, a newly published segment can generate up to 100 origin requests (one per PoP) before any of them are warm. With a shield, the first PoP to miss fetches through the shield to origin; the other 99 fetch from the shield. Origin requests per object drop from a hundred to one.
For a live event, this is the difference between an origin that idles and an origin that falls over. Cache miss traffic to origin is often described as thundering herd, and the shield is the standard remedy.
Place the shield in a region close to your origin, since the shield-to-origin hop is the one you are trying to make rare and cheap. Some CDNs enable a shield by default; many do not, and it is worth checking rather than assuming.
Segment Duration and Request Volume
Segment duration is usually chosen for latency reasons, but it has a direct effect on CDN economics.
Halving segment duration doubles the number of objects and doubles request volume. For a service billed partly per request, that is a real line item. It also doubles the number of distinct cache entries, which slightly reduces the proportion of the catalogue that stays resident in any given PoP's cache.
Four to six seconds is the common compromise for standard latency. Below two seconds you are usually in low-latency territory, where request volume increases dramatically and the CDN needs specific capabilities anyway.
Prefetching and Cache Warming
Video has a property most web content lacks: the next request is entirely predictable. A player fetching segment 42 will fetch segment 43 next, from the same representation, within seconds.
Several CDNs can exploit this by prefetching subsequent segments into the edge cache on a miss. For live streams especially, this converts what would be a miss for the first viewer at each PoP into a hit.
The related technique for scheduled events is cache warming, deliberately requesting content into edge caches before an audience arrives. This is most valuable for a VOD release with a known publish time, where a large audience arrives simultaneously for content no cache has ever seen.
Measuring the Right Things
Overall cache hit ratio is a poor summary metric for video because it averages together objects with completely different behaviour. Break it out:
• Hit ratio by object type. Segments should be well above 95 percent in steady state. Manifests will be lower by nature. A combined figure hides both.
• Origin egress volume, not just request count. A low miss rate on multi-megabyte segments can still be substantial origin bandwidth.
• Hit ratio by representation. The top rung of your encoding ladder is requested least and will cache worst. If it is dominating origin traffic, that is expected, and a reason to check whether the rung is earning its place.
• Time-to-first-byte at the edge, split by hit and miss. A large gap indicates the origin path needs attention; a small gap means misses are cheap and you can be less aggressive elsewhere.
A Reasonable Starting Configuration
For a typical VOD and live service:
Plus an origin shield, a cache key stripped of session and analytics parameters, and prefetching enabled if available.
That configuration handles the large majority of video workloads. The remaining tuning is specific to your traffic shape, and the metrics above are what tell you where to look.