Design a Video Streaming Service
2 min read
Design a Video Streaming Service (YouTube / Netflix)
Two very different problems: processing huge uploads, and delivering video to millions smoothly.
1. Requirements
- Functional: upload; transcode to multiple qualities; stream; search & recommend.
- Non-functional: massive storage, global low-latency delivery, adaptive quality. Extremely read-heavy.
2. The upload & processing pipeline
Upload ─▶ Raw store (S3) ─▶ Queue ─▶ Transcoding workers
│
┌─────────┼──────────┐
240p 720p 1080p (+ HLS/DASH chunks)
- Store the raw upload in object storage.
- A queue feeds transcoding workers that produce multiple resolutions, split into small segments (~2–10 s) with a manifest.
3. The delivery problem: adaptive bitrate
Video is served via HLS / DASH: the client reads a manifest, then picks the quality matching current bandwidth — switching mid-playback to avoid buffering.
- Segments & manifests are cached on a CDN — the origin barely sees playback traffic.
4. Data model
videos: id | uploader_id | title | status | duration | created_at
assets: video_id | resolution | bitrate | cdn_url | manifest_url
Metadata in a DB; the actual bytes live in object storage + CDN, never in the DB.
5. Deep dives
- Storage tiering: hot videos on CDN; cold archives on cheap storage.
- Resumable uploads: chunk large uploads so a dropped connection doesn't restart from zero.
- Recommendations: a separate ML pipeline over watch history.
Takeaway: separate the write path (upload → queue → transcode → store) from the read path (manifest → adaptive segments → CDN). The CDN makes global streaming affordable.