We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
2 system design questions lean on this idea. Each walks through the full answer.
System Design Masterclass · Web Content Delivery
Free preview: the first 2 parts of this 6-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Web Content Delivery
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
You cannot download a 2-hour movie before watching it. Not because the file is too large (it is, at 4-8 GB for 1080p), but because users expect playback to start within 2-3 seconds of pressing play. Streaming protocols solve this by delivering video in small chunks so the player can start rendering before the full file arrives.
The problem is harder than it sounds. The video must play smoothly even when bandwidth fluctuates. The protocol must work on iPhones (Apple controls what plays in Safari), Android phones, smart TVs, and web browsers. It must support live events (Super Bowl, breaking news) where matters, and on-demand content (Netflix, YouTube) where efficiency matters more.
Three protocol families dominate the market. HLS (Apple's protocol) controls iOS and Safari. DASH (open standard) controls everything else. WebRTC (peer-to-peer) handles real-time communication where even 1 second of latency is too much. A fourth, CMAF, is a packaging format that bridges HLS and DASH, letting you produce one set of segments that both protocols can reference.
HLS ( Live Streaming). Apple created it in 2009. The player downloads a manifest file (.m3u8) that lists segment URLs and available bitrates. Each segment is 2-10 seconds of video. Safari and iOS play HLS natively. Android and Chrome play it through MSE (Media Source Extensions) or libraries like hls.js. Default segment duration is 6 seconds, giving a minimum live of 18-30 seconds (3 segments buffered). Low-Latency HLS (LL-HLS) reduces this to 2-4 seconds using partial segments and server push.
DASH (Dynamic Adaptive Streaming over HTTP). MPEG industry standard from 2012. Manifest is an .mpd XML file. Codec-agnostic (supports H.264, H.265, VP9, AV1). Used by YouTube, Netflix (non-Apple devices), Disney+, Amazon Prime Video. More flexible than HLS in terms of manifest structure, but the flexibility creates implementation complexity. The two main players are dash.js (reference implementation) and Shaka Player (Google).
CMAF (Common Media Application Format). Not a streaming protocol, but a container format that unifies HLS and DASH. Both protocols point to the same fragmented MP4 segments. You encode and package once, and both HLS and DASH manifests reference the same segment files. Saves 50% on storage and cache usage compared to maintaining separate HLS (.ts) and DASH (.m4s) segments. Apple and Microsoft co-proposed CMAF in 2016.
WebRTC (Web Real-Time Communication). Peer-to-peer protocol for ultra-low-latency communication. Sub-500ms latency. Used by Zoom, Google Meet, Discord (video), and Twitch's low-latency mode. Not HTTP-based, so CDN does not apply. Scales through SFU (Selective Forwarding Unit) servers that relay streams without decoding them. Not suitable for on-demand video because there is no built-in seeking, DVR, or CDN caching.