The CDN as most people understand it was built for Netflix and YouTube — cache a file once, serve it a million times. Live linear TV breaks that model completely. Here’s why, and what live actually needs.
‘Just put it on a CDN’ is the most confidently wrong sentence in live streaming. The CDN most people picture was designed for video-on-demand, and live linear violates almost every assumption it’s built on.
A Netflix or YouTube file is written once and served millions of times. The first viewer pulls it to the edge; everyone after that gets a cache hit. Hit ratios approach 100%, the origin is barely touched, and adding edges linearly adds capacity. This is what ‘CDN’ was optimised for.
Live linear produces a new segment every few seconds, forever. The most-wanted segment is the one that doesn’t exist yet. Your cache window is only as wide as a few seconds of stream. Worse, at every segment boundary, thousands of players ask the edge for the same brand-new segment at the same instant — a thundering herd that, if the edge misses, slams straight into the origin.
VOD caching answers ‘serve this file a million times’. Live caching has to answer ‘serve a file that was born two seconds ago to fifty thousand people at once, then throw it away’. They are different problems with different architectures.
For set-top boxes inside a supporting ISP network, multicast removes the herd problem completely — one copy of the channel serves everyone, no per-viewer segment fetch. The unicast edge then only carries the OTT app audience. This is why the real design is hybrid, and why a naive ‘pull-CDN for everything’ both over-costs and under-performs.
HySky’s edge does shield + request-coalescing for the unicast (app) path, and drives multicast on-net for STBs. Edges are sized against concurrency, and live segments are served from the nearest PoP with the origin protected behind the shield. The result: the origin stays quiet even during a big-match segment storm.
Talk to a team that runs a live operator, not just sells software.
