CDN Delivery and Caching for Streaming Video

Your encoder ladder and ABR algorithm decide what the player could fetch, but the CDN decides what actually arrives, how fast, and how cheaply. For a streaming service, CDN behavior is the single biggest lever on both cost and QoE. This post covers how segments travel from origin to edge, what makes them cacheable, how cache hit ratio drives everything, and how to correlate player experience with CDN logs using CMCD.

Origin to edge

A streaming CDN is a hierarchy of caches between your origin (where the packager writes segments and manifests) and the viewer:

1. Origin — stores or generates segments and manifests.
2. Mid-tier / shield cache — a regional cache that consolidates requests so the origin sees far less traffic (origin shielding).
3. Edge PoP — the cache physically near the viewer that serves most requests.

On a cache miss, the edge fetches up the chain to the shield and, if needed, the origin. On a hit, it serves from local storage and the origin never sees the request. The entire economics of streaming rests on maximizing hits.

Cache keys: what counts as "the same object"

The CDN identifies a cached object by its cache key — by default the URL, but configurable. Getting this right is critical:

• Strip irrelevant query strings. Session tokens, analytics params, and CMCD query data must be excluded from the cache key, or every viewer generates a unique URL and your hit ratio collapses to near zero.
• Include what genuinely varies the bytes — e.g. a CDN token's signature should be validated but not be part of the key, while a true content variant (different language track) should be.
• Beware Vary headers. Vary: Accept-Encoding is fine; varying on cookies or user-agent fragments the cache.

A classic production incident: CMCD sent as query args ends up in the cache key, and a healthy 95% hit ratio drops to 10% overnight. Always send CMCD as a header (CMCD-Object, CMCD-Request, CMCD-Session, CMCD-Status) where possible, or configure the CDN to ignore the CMCD query parameter in the key.

Cache hit ratio is the metric

Cache hit ratio (CHR) — the fraction of requests served from edge cache — determines origin load, delivery cost, and latency. A few percent of CHR is enormous at scale.

What drives CHR:

• Catalog concentration. Popular live events and hit titles cache trivially; long-tail VOD has many cold objects.
• Segment cacheability (below).
• Per-session URLs. SSAI personalized manifests and tokenized URLs reduce shared cacheability — design them so the media segments stay shared even when manifests are unique.

Segment cacheability

Make the bytes cacheable and keep them cacheable long enough:

• VOD segments are immutable — set long Cache-Control: max-age (hours to days) and immutable. They never change; cache them aggressively.
• Live media segments are also immutable once written — a segment for a past moment never changes, so cache it long. Only the manifest changes.
• Live manifests need short TTLs — they update every segment/part, so cache for a fraction of the segment duration (or use no-cache with revalidation). This is where origin load concentrates on live.
• Use consistent, content-addressed URLs so the same segment is one cache key everywhere.

# media segment (immutable)
Cache-Control: public, max-age=31536000, immutable

# live media playlist (frequently changing)
Cache-Control: public, max-age=1, stale-while-revalidate=2

Why small segments matter

Segment duration is a CDN tradeoff, not just a latency one:

• Smaller segments (2s, or sub-second parts in LL-HLS) reach the live edge faster and let ABR react quicker — but multiply request count, raising request-per-second load and per-request overhead on the CDN.
• Larger segments (6–10s) are more cache- and throughput-efficient and reduce request volume — but increase live latency and slow ABR adaptation.

Most VOD lands around 4–6s; low-latency live pushes to 2s segments with sub-second parts. See Low-Latency HLS and CMAF for how parts change the request profile.

Prefetch and warming

• Cache warming / prefetch — for a big live event or new release, push popular segments to edges before demand spikes so the first viewers don't all miss.
• Player-side prefetch — players fetch the next segment(s) ahead of the playhead; preload hints in LL-HLS extend this to parts.
• Tiered prefetch — the edge can prefetch the next segment from the shield when it serves the current one, smoothing the request pattern for sequential media.

Multi-CDN and switching

Serious services run multiple CDNs for resilience, geographic coverage, and cost negotiation. Switching strategies:

• DNS / steering at session start — a request-routing service picks a CDN per session based on geo, real-time performance (RUM), and cost.
• Mid-stream switching — the player (or a manifest-level mechanism like DASH BaseURL lists / Content Steering) can fail over to another CDN if one degrades. HLS/DASH Content Steering provides a standardized steering manifest the player polls to re-rank CDNs.
• Measurement-driven — switching decisions are only as good as your data, which is where CMCD comes in.

CMCD for CDN log correlation

The hardest part of CDN operations is connecting what the player experienced to what the CDN logged. CMCD (Common Media Client Data, CTA-5004) solves this: the player attaches structured data to each media request, which the CDN records in its logs.

Useful CMCD keys:

• sid — session ID, ties all of a session's requests together (and to your QoE beacons).
• cid — content ID.
• bl — buffer length (ms remaining); a low bl near a stall is a smoking gun.
• br — encoded bitrate of the object.
• mtp — measured throughput.
• dl — deadline; how urgently the object is needed.
• bs — buffer-starvation flag; the player set this when it stalled.
• rtp — requested maximum throughput.

CMCD-Request: bl=21000,dl=4000,mtp=15000,su
CMCD-Object: br=4500,d=4000,ot=v
CMCD-Session: sid="a1b2c3",cid="movie-42",sf=h,st=v
CMCD-Status: bs,rtp=18000

With sid in both CMCD and your QoE beacons, you can join a viewer's rebuffering event to the exact CDN edge, cache status (hit/miss), and latency for the request that starved the buffer. Explore CMCD payloads and the header-vs-query tradeoff in the CMCD tool.

Takeaways

CHR is the metric that drives cost and QoE; protect it by keeping cache keys clean (CMCD as headers, not query args) and segments immutable with long TTLs. Use multi-CDN with steering for resilience, prefetch for big events, and CMCD to finally correlate player pain with CDN reality. When a region's rebuffering spikes, CMCD plus CDN logs turn "the CDN is slow" into "edge X had a 40% miss rate on the 4500k rendition."