A live stream is a chain: encoder, packager, origin, CDN, player. The first half is a video engineering problem; the second half is a delivery problem, and it is where streams fall over at scale — because live traffic is the most synchronized load a CDN ever sees. Every viewer wants the same few files within the same few seconds, which is either the best cache scenario in the business or a coordinated assault on your origin, depending entirely on configuration.
The chain, and where the CDN sits
The encoder turns the camera feed into compressed video and pushes it (typically over RTMP or SRT) to a packager, which cuts it into segments and writes manifests — HLS playlists, DASH MPDs — onto an HTTP origin. From there the stream is just files, and the CDN’s job is to fan those files out. That framing matters: the CDN never touches RTMP or your encoder; its world begins at the packager’s HTTP output. So the delivery design questions are the familiar ones — cache keys, TTLs, origin protection — applied to an unusual traffic shape: a small set of objects, requested by everyone, replaced every few seconds. Choosing between the two manifest formats is its own decision; our HLS vs DASH comparison covers it, and everything below applies to either.
The three cache classes of a live stream
A live stream has exactly three kinds of object, and they want opposite treatment. Media segments are immutable — segment 4812 never changes — so cache them long (hours is fine; the playlist controls what players fetch, not the segment TTL) and let the edge absorb essentially all segment traffic. Init segments and the master playlist change rarely; minutes of TTL is safe. The live media playlist is the opposite: it updates every segment interval, and its TTL is the lever that trades origin load against latency. Set it to roughly half a segment duration — one to three seconds for typical six-second segments — never zero (a no-store manifest sends every viewer’s polling to the origin) and never long (a stale manifest is a frozen stream). Getting these three classes wrong in either direction is the root of most live incidents: segments with short TTLs melt origins; manifests with long TTLs stall players.
Origin design: packager, shield, collapsing
Even with correct TTLs, a global audience means hundreds of edge locations each missing on every new segment and manifest version within the same second. Two features turn that thundering herd into a trickle. Request collapsing (coalescing) makes each cache node forward one request per object and hold the duplicates — essential for live, and worth verifying rather than assuming, since implementations differ on whether they collapse while a response is still streaming. An origin shield adds a single mid-tier so the origin sees one fetch per object per shield rather than per edge; for live it is close to mandatory, and the mechanics are in configuring origin shield. Behind that, keep the origin boring: the packager writes to storage or a small HTTP tier that does nothing clever, sends correct Cache-Control per class from section two, and is sized on the assumption that collapsing occasionally fails open. Redundancy means two encoder-packager pipelines writing parallel outputs, with a tested switch — not one pipeline with hope.
Protocol and segment choices that affect delivery
Segment duration sets your baseline latency: players typically buffer around three segments, so six-second segments put you twenty-plus seconds behind live, while two-second segments cut both latency and startup at the cost of more requests and slightly worse encoding efficiency — a real trade at very large scale, since per-request costs and manifest churn scale up together. Package once in CMAF so HLS and DASH share the same media files and your cache stores one copy instead of two. Serve segments over HTTP/2 or HTTP/3 to viewers, keep manifest and segment URLs on one hostname so connections are reused, and if the event genuinely needs hand-clap latency, that is the low-latency variants’ territory — a materially more demanding chain covered in low-latency HLS and DASH. For most live content, well-tuned standard delivery at two-to-six-second segments is the right amount of ambition.
Bring-up checklist and the first test event
Before the first real event: confirm the three cache classes by inspecting response headers at the edge (segment hit ratios should sit in the high nineties within a minute of stream start); prove collapsing and shield behaviour by watching origin request rates while synthetic viewers scale up; kill the encoder mid-stream on purpose and watch what players do with the stale manifest; and rehearse the failover to the second pipeline. Then run a dress rehearsal at realistic scale — a load test or a low-stakes stream — before the event that matters, because live delivery problems only show up under synchronized audiences. Capacity arithmetic and the rehearsal-day drill for genuinely big events are in running delivery for a live event.