Design interviews / Intermediate / 6 min
Design YouTube: upload, transcode, publish
A worker pool turns uploads into 240p to 1080p. Split videos into segments, publish low quality first, and match workers to the upload rate.
Start the simulation → Change the load, break a part, watch what happens. Free, no sign-up.
In short
- What it is
- YouTube stores the raw upload, splits it into segments, transcodes each into several qualities on a worker pool, then publishes playlists for streaming.
- Why it matters
- Transcoding is the heaviest step and every viewer needs a quality that fits their screen and network.
- The trade-off
- More workers cut waiting but cost money while idle; publishing low quality first is fast, but early viewers see a blurry picture.
- Say it in an interview
- "Resumable upload to object storage, a queue of per-segment transcode jobs on autoscaled workers, HLS/DASH renditions to the CDN, and a status service that flips the video live."
Check yourself
Why split a video into short segments before transcoding?
Answer: Many workers can transcode one video at the same time, so it finishes much sooner. A whole-file 1080p job runs on one worker; segments spread the same work across the pool.
What does publishing the 240p version first buy?
Answer: Viewers can start watching in seconds while higher qualities finish. Low quality is cheapest to make; the player switches to sharper versions once they exist.
Uploads arrive faster than the workers can transcode. What happens?
Answer: The job queue grows without limit until more workers are added. Throughput must be at least the arrival rate; otherwise waiting time keeps growing (autoscale the pool on queue length).