Designing a Global Video Streaming Platform (YouTube / Netflix)
Architect a globally distributed video streaming system handling petabyte-scale storage, asynchronous chunked transcoding (HLS / DASH), CDN edge caching, and adaptive bitrate streaming.
Functional Requirements
- •Upload video files up to 10GB
- •Adaptive Bitrate (ABR) video playback across resolutions (360p to 4K)
- •Global search and view count tracking
Non-Functional Requirements
- •High availability (99.99%)
- •Ultra-low buffering latency (<200ms TTFB)
- •Zero data loss for uploaded media
Capacity & Scale Estimation
Core Architectural Components
1Upload Service & Chunking
Receives multi-part file chunks, uploads to temporary S3 staging bucket, and triggers async transcoding event to Kafka.
2Transcoding Pipeline (DAG)
Distributed worker pool (FFmpeg) splits video into 6-second segments, encodes into multiple resolutions (AV1/H.265), and outputs HLS/DASH manifest (.m3u8).
3Global Edge CDN (Cloudflare/CloudFront)
Caches video segments at regional edge points of presence (PoPs) to serve 95%+ of video bytes without hitting origin servers.
4Metadata & Search Cluster
PostgreSQL for transactional metadata + Elasticsearch cluster for sub-second video search indexing.
Architectural FAQs & Interview Deep Dives
How does Adaptive Bitrate (ABR) streaming work?
The client video player dynamically monitors available network bandwidth and buffer health every 6 seconds, automatically switching between 1080p, 720p, and 480p chunk streams without stuttering.
How do you count video views at scale without database locks?
Views are buffered in Redis memory counters or Kafka streams and batch-flushed to persistent databases every 5 minutes to prevent DB write bottlenecks.