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