Design a Video Platform (YouTube)
Upload, transcode, store, and stream video to billions with adaptive bitrate and a global CDN.
Overview
A video platform ingests uploads, transcodes them into multiple resolutions/formats, stores petabytes durably, and streams adaptively to viewers worldwide. It's the canonical storage + CDN + async-pipeline problem, with the added twist of enormous, cacheable static content.
Requirements
Functional
- Upload videos of arbitrary size and format.
- Transcode into multiple resolutions and codecs.
- Stream with adaptive bitrate (HLS/DASH) and support seeking.
- Search, recommendations, view counts, and comments.
Non-functional
- Smooth playback globally with low startup latency and no rebuffering.
- Durable storage of petabytes; upload availability.
- Extremely read-heavy and highly cacheable at the edge.
Back-of-the-envelope
The numbers that justify the architecture.
| Uploads / day | ~1M hours | |
| Views / day | 5B+ | |
| Storage / day | ~PB | raw + multiple transcoded renditions |
| Egress | dominated by CDN | most cost + traffic |
Reference architecture
A chunked-upload path lands raw video in blob storage and triggers an async transcoding pipeline; playback is served as segmented files from a CDN with a lightweight metadata service.
Deep dives
Resumable, chunked upload
Large files over flaky networks need chunked, resumable uploads: the client splits the file, uploads parts (often directly to blob storage via presigned URLs), and can resume failed parts. The upload service records progress and, on completion, drops a job on the transcoding queue. Uploading straight to S3 keeps huge byte streams off your application servers.
The transcoding pipeline
Raw video is useless for streaming. An async pipeline transcodes each upload into a ladder of resolutions (240p→4K) and codecs, then segments each rendition into short chunks (e.g., 2–6 s) with a manifest (HLS `.m3u8` / DASH `.mpd`). This is embarrassingly parallel — a DAG of workers per segment — so it scales horizontally and processing time is bounded by the slowest segment, not the whole file. Store segments in blob storage.
Adaptive bitrate streaming
The player fetches the manifest, then requests segments at a bitrate matched to current bandwidth, stepping up/down per segment to avoid rebuffering. Because segments are immutable static files, they're perfectly CDN-cacheable — the CDN, not your origin, serves ~all playback bytes. Pre-warm popular content to the edge; cold long-tail content pulls through on first request.
Read scale and metadata
Views vastly outnumber uploads and are highly skewed (a few videos get most traffic). Serve bytes from CDN; keep a small metadata service (title, owner, rendition manifest URLs, view count) backed by a sharded DB and cache. View counts are high-write — buffer and aggregate them asynchronously rather than incrementing a row per view.
Key trade-offs
For each decision: the two options, and when to pick which.
Bottlenecks & follow-ups
Where it breaks under load — and what an interviewer will probe.
- ▲Transcoding compute → parallelize per-segment; autoscale worker pools.
- ▲Origin egress → aggressive CDN caching + edge pre-warming.
- ▲View-count write amplification → async aggregation, not per-view writes.
What a strong answer sounds like
- ✓Split the design into three pipelines: upload, transcode, playback. Don't blur them.
- ✓Say 'segments are static → CDN serves playback' — it's the load-bearing insight.
- ✓Treat transcoding as a parallel DAG; it shows you understand the async pipeline.