# System Design Interview: Video Streaming Platform (Netflix/YouTube) Source: https://www.techinterview.org/post/3233461351/system-design-video-streaming-platform/ Updated: 2026-04-16 · techinterview.org Designing a video streaming platform like Netflix or YouTube is one of the most comprehensive system design challenges, combining video processing pipelines, CDN architecture, adaptive bitrate streaming, and personalization at massive scale. ## Core Requirements **Functional:** Upload videos, transcode to multiple resolutions/formats, stream to users on any device with adaptive quality, support search and recommendations, track view history and progress. **Non-functional:** 200M daily active users. 1B hours of video watched per day. Upload processing within 30 minutes. Stream start time < 2 seconds. 99.99% availability. Support 4K, 1080p, 720p, 480p, 360p. ## Video Upload and Processing Pipeline ``` Upload flow: Creator → Upload API → S3 (raw video, presigned PUT URL) → SQS: "video uploaded" event → Video Processing Worker Processing pipeline stages: 1. Validation: check video format, duration, file integrity (SHA-256) 2. Transcoding: convert to multiple resolutions and formats Tool: FFmpeg (open source) or cloud services (AWS MediaConvert) Output per video: 360p H.264 MP4 (mobile, low bandwidth) 480p H.264 MP4 720p H.264 MP4 (standard HD) 1080p H.264 MP4 1080p H.265 HEVC (50% smaller than H.264) 4K H.265 (if source is 4K) Audio-only AAC (for background play) 3. Thumbnail generation: extract frames at 10s intervals 4. Content moderation: run ML classifier (NSFW, copyright) 5. Packaging: segment into chunks for adaptive streaming (HLS/DASH) 6. CDN distribution: push to edge PoPs 7. Update DB: mark video as available, publish event Distributed transcoding: Split 2-hour movie into 5-minute segments Transcode each segment in parallel across N workers Merge segments → final output Reduces 2-hour 4K transcode from 8 hours → 30 minutes ``` ## Adaptive Bitrate Streaming (ABR) ``` Problem: users have different bandwidths; static quality = bad UX (buffering on slow connections, blurry on fast connections) ABR: client switches quality mid-stream based on current bandwidth HLS (HTTP Live Streaming) — Apple, widely supported: Master playlist (m3u8): #EXTM3U #EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360 360p/index.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=2800000,RESOLUTION=1280x720 720p/index.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080 1080p/index.m3u8 Each quality-level playlist (360p/index.m3u8): #EXTM3U #EXT-X-TARGETDURATION:6 #EXTINF:6.0, segment_001.ts #EXTINF:6.0, segment_002.ts ... Client logic: - Download master playlist → pick initial quality based on bandwidth estimate - Download segments → measure download speed - Buffer > 20s, high speed: switch to higher quality - Target: maintain 20-30s buffer for smooth playback ``` ## CDN Architecture ``` Video storage distribution: Origin: S3 (all video segments, all qualities) CDN (CloudFront / Akamai / Fastly): 300+ PoPs worldwide Each PoP caches popular video segments Cache hit ratio: ~80% (hot content cached at edge) Cache miss → origin pull → cache at edge (5-10s penalty) Cache key: {video_id}/{quality}/{segment_number}.ts e.g., cdn.netflix.com/v/xyz123/1080p/segment_042.ts Popular content (top 10%): pre-warmed at all PoPs When video is trending → push-based distribution to edge Long-tail content: served from nearest PoP or origin on-demand First viewer in a region pulls from origin → cached for next viewers Cache TTL: Video segments (immutable): Cache-Control: max-age=31536000 (1 year) Playlists (can change): Cache-Control: max-age=5 (live) or 60 (VOD) ``` ## Video Storage Architecture ``` Storage tiers by access frequency: Hot tier ( 180 days, 2 years, rarely accessed): S3 Glacier Deep Archive Cost: $0.00099/GB/month, 12-48 hour retrieval Lifecycle policy (automated): Day 0: S3 Standard Day 30: → S3-IA Day 180: → Glacier Day 730: → Glacier Deep Archive Storage at YouTube scale: 500 hours of video uploaded per minute Avg 1 hour = 2GB raw = 1GB after transcoding (all qualities) 500 GB/min = 720TB/day = 263PB/year ``` ## Database Design ``` videos table (PostgreSQL/Spanner): id UUID PRIMARY KEY title TEXT description TEXT creator_id BIGINT status ENUM(processing, published, removed) duration_sec INT view_count BIGINT DEFAULT 0 published_at TIMESTAMPTZ INDEX (creator_id, published_at DESC) INDEX (status, published_at DESC) -- for feed queries video_qualities table: video_id UUID quality ENUM(360p, 480p, 720p, 1080p, 4K) storage_path TEXT -- S3 key size_bytes BIGINT PRIMARY KEY (video_id, quality) view_events (ClickHouse / BigQuery — analytics): event_id UUID video_id UUID user_id BIGINT started_at TIMESTAMPTZ watch_secs INT quality TEXT device TEXT country TEXT user_watch_history (Cassandra — high write rate): user_id BIGINT PARTITION KEY video_id UUID CLUSTERING KEY (descending by watched_at) watched_at TIMESTAMPTZ progress_sec INT -- resume position ``` ## View Counter at Scale ``` Problem: 1B views/day = 11,600 views/sec Incrementing DB view_count per view → DB bottleneck Solution: counter aggregation Redis INCR video:views:{video_id} (atomic, fast) Background job every 30s: - Flush Redis counters to DB in batch - GETSET video:views:{video_id} 0 (atomic read + reset) - UPDATE videos SET view_count = view_count + {delta} WHERE id = ? Approximate counts (YouTube approach): Only update DB when count crosses thresholds: 100, 1000, 10000, ... Display: "1.2M views" is fine — exact count unimportant Milestone events: On write: check if new count crosses 1M, 10M, 100M milestones → Trigger: notify creator, update trending algorithm, badge ``` ## Live Streaming Architecture ``` Live streaming vs VOD (Video on Demand): VOD: entire video pre-processed; segments pre-generated Live: real-time encoding; low latency required Live ingest: Creator → RTMP client (OBS, mobile app) → RTMP ingest server → Transcoder: encode to HLS segments in real-time → 2-second segment length (lower = lower latency, more requests) → S3 + CDN: segments available ~6 seconds after capture Ultra-low latency (WebRTC for < 1s delay): Used for: interactive live streams, auctions, sports betting WebRTC peer-to-peer or SFU (Selective Forwarding Unit) architecture See: System Design: WebRTC and Real-Time Video Architecture ``` ## Interview Discussion Points - **Why segment videos into small chunks?** Seekability: client jumps to any position by calculating the segment number. Adaptive quality: client switches quality at segment boundaries. Resilience: download one segment at a time; network interruption → just re-download that segment. - **H.264 vs H.265 trade-off?** H.265 (HEVC) produces 50% smaller files at equivalent quality, but requires 4× more CPU to encode. For Netflix: H.265 saves significant CDN costs at scale. Browser support: H.265 not universally supported (Edge yes, Chrome partially) → must serve both formats based on client capabilities. - **How does Netflix achieve < 2s start time?** Pre-buffer: on hover, client fetches the first 5 segments of the most likely quality. Predictive pre-loading: user's network measured, quality pre-selected before play button is clicked. CDN PoP selection: DNS routes to nearest PoP with the content cached. - **How to handle concurrent viewers for a viral video?** The CDN absorbs the load — each PoP serves its regional audience from local cache. The origin server (S3) only handles CDN miss requests. For truly global events (World Cup), pre-distribute all segments to all PoPs hours before kickoff. - [LinkedIn Interview Guide](https://techinterview.org/linkedin-interview-guide/) - [Cloudflare Interview Guide](https://techinterview.org/cloudflare-interview-guide/) - [Databricks Interview Guide](https://techinterview.org/databricks-interview-guide/) - [Twitter/X Interview Guide](https://techinterview.org/twitter-interview-guide/) - [Snap Interview Guide](https://techinterview.org/snap-interview-guide/) - [Meta Interview Guide](https://techinterview.org/meta-interview-guide/) ## Companies That Ask This - [Netflix Interview Guide](https://techinterview.org/netflix-interview-guide/)