Art of Codeartofcode
Lesson 8 of 16

40. Design Video Upload and Streaming (YouTube)

1
The interview prompt
2
40.1 What do you ask first?
3
40.2 How big is this, really?
4
40.3 What are the doors?
5
40.4 What do we store?
6
40.5 What does the whole system look like?
7
40.6 How does the upload pipeline work?
8
40.7 How does transcoding work?
9
40.8 How does adaptive bitrate work?
10
40.9 How does CDN delivery work at this scale?
11
40.10 How do you count views?
12
40.11 What would you say in the last five minutes?
13
Score yourself
14
Variations to practise
15
Sources
16
Code lab
40. Design Video Upload and Streaming (YouTube)

40.7 How does transcoding work?

3 min read+10 XP

the original is split into 6-second segments; 100 workers encode them in parallel into five qualities; the results are stitched into playlists.

Figure: split, encode in parallel, stitch.

  • Why transcode: raw uploads come in every format, resolution and bitrate. Viewers need standard codecs (H.264 everywhere, VP9 and AV1 for efficiency where supported) at several qualities, cut into segments with playlists.
  • Parallelise by segment: split the video at keyframes into short segments, encode each independently on a separate worker, then stitch the playlists. In the chapter's code, a 10-minute video takes 20 minutes on one worker but about 12 seconds across 100 workers (plus queueing).
  • A pipeline (DAG) of steps: inspect → split → encode each quality → package (HLS/DASH) → thumbnails → publish. An orchestrator tracks each step and retries failures.
  • Scale with the queue: workers autoscale on queue depth (Chapter 22); cheaper interruptible machines work because each segment job is short and retryable.
  • Publish progressively: 360p first so the video is watchable within minutes; 1080p and 4K follow.

Memory code: "Cut at keyframes, encode in parallel, publish the small ones first."