CDN for video delivery

Why segmented video caches so well

A CDN cache works by URL. A request arrives at an edge server. If that server holds a fresh copy of the object at that URL, it responds at once. If not, it fetches the object from the origin, or from a larger cache in between, stores it and responds. Segmented streaming, as described in the HLS guide, produces exactly the kind of object caches love: small, immutable files with unique names, requested by many viewers in roughly the same order.

The arithmetic is simple. A popular video at 1080p might be five thousand segments across all renditions. Each is fetched from the origin once per edge location. After that, every viewer near that location is served from cache. The origin sees a trickle, the edges see the flood, and the flood is what CDNs are built for. A monolithic MP4 served with byte-range requests caches far less predictably, because different players request different ranges.

What to cache, and for how long

Cache lifetimes are set with Cache-Control headers from the origin. These are typical patterns, not fixed rules.

Live streams: the same objects, a harder timeline

For on-demand video the CDN can treat everything as static, and a cold cache simply warms as the first viewers arrive. Live changes the timing. Every viewer wants the newest segment within seconds of it being written, so thousands of requests for the same URL hit the edge before it has a copy. A well-designed CDN collapses those into one origin fetch (request coalescing) and holds the others until the object arrives, rather than forwarding each to the origin.

The live playlist is the other pressure point. It is small, changes every few seconds, and is polled by every viewer. Setting its cache lifetime to a fraction of the segment duration keeps viewers close to the live edge without sending every poll to the origin. Low-latency modes, described in the HLS vs DASH comparison, push further with partial segments and blocking requests, and need CDN support for them specifically.

How a segment request travels

1. The player resolves the segment hostname. The CDN's DNS or anycast routing returns the address of a nearby edge location rather than the origin.
2. The edge checks its cache for the exact URL, including any query string that forms part of the cache key. A hit is served at once.
3. On a miss, the edge asks an origin shield. This is a regional cache placed between the edges and the origin, so one region's many edges make one upstream request, not many.
4. On a shield miss, the shield fetches from the origin, stores the object with the origin's Cache-Control lifetime and passes it back down to the edge.
5. The edge stores it and serves it. Every later request for that URL from that region is a cache hit until the lifetime expires or the object is evicted.

Access control without breaking the cache

Caching and privacy pull in opposite directions. A private video must not be served to anyone who guesses the URL, but per-user checks on every segment would defeat the cache. The standard resolution is a signed URL or signed cookie: the origin issues the player a token, embedded in the URL or a cookie, that encodes an expiry and a signature the edge can verify without contacting the origin. The segment itself is cached once; the check happens at the edge on each request.

Some content must be encrypted at rest and in transit. For that, HLS carries the key URL in the playlist, and the player fetches the key separately. So keys can be protected with the same token method while the encrypted segments stay fully cacheable. On VideoBB the per-video privacy settings (public, unlisted and private) decide who may reach a stream; the help centre explains how each behaves.

Mechanisms that move the needle

Where the costs hide

• Egress. CDN pricing is dominated by bytes delivered, and every rendition a viewer watches is bytes delivered. So an efficient encoding ladder, as described in the transcoding guide, is also a cost control.
• Origin egress. A low cache hit ratio means the origin, often a cloud storage bucket with its own bandwidth pricing, serves far more than it should. Shields and long segment lifetimes are the fix.
• Small audiences spread thin. A video with ten viewers in ten countries produces ten cold-cache fetches and little benefit from caching at all; this is normal and not a fault.
• Cache churn. Very short segments multiply object counts; very large libraries can exceed edge storage so that unpopular content is evicted and re-fetched. Neither is dramatic for most sites, but both show up in the origin bill.