HLD10 min read
Design YouTube / Netflix
Adaptive bitrate streaming, edge CDNs, and the upload → transcode → publish pipeline.
hldsystem-design
Intro
Video platforms split cleanly into two flows: ingest (upload → transcode → publish) and playback (manifest → segment fetch via CDN). Most of the architectural weight is in the second.
Functional
- Upload videos with metadata.
- Stream with adaptive bitrate (HLS / DASH).
- Search and recommendation.
Non-functional
- Buffer-free playback at p99 across geographies.
- Petabyte-scale storage; thousands of edges.
- Encode SLA: < 1 hour for typical uploads.
Components
Upload API
Resumable uploads (TUS-style) to object store.
Transcoding pipeline
Workers that produce HLS / DASH ladders (240p…4K).
Manifest service
Serves .m3u8 / .mpd; tiny payload, very high QPS.
Origin storage
Object store; warmed via CDN miss.
CDN
Edge caches with regional shielding.
Recommender
Offline-trained model serving via low-latency embedding store.
Trade-offs
Push to all edges vs. pull-on-demand
Pros
- Push prefills hot videos before traffic.
- Pull saves bandwidth on cold catalogue.
Cons
- Push wastes for unviewed videos; pull pays first-view latency.
HLS vs. DASH
Pros
- HLS is well supported on iOS.
- DASH is more flexible / standards-aligned.
Cons
- Both — production usually serves both.
Scale concerns
- Hot premiere → rapidly heat the CDN; use 'pre-positioning' for known launches.
- Encode is expensive — schedule in off-peak hours when possible.
- Region failover for ingest; CDN provider failover for delivery.