Art of Codeartofcode
Lesson 5 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.4 What do we store?

3 min read+10 XP
originals object storage (cold tier after processing) v77/original.mp4 renditions object storage + CDN v77/720p/seg00042.ts, v77/master.m3u8 videos video_id, owner, title, status (uploading | processing | ready | failed), duration, renditions available, created_at (sharded SQL or wide-column) jobs video_id, step, state, attempts (processing pipeline state) view_counts video_id → count (sharded counters, flushed periodically)

Interviewer pushback:

  • "Why keep the original after transcoding?" → To re-encode later with better codecs or new qualities without asking the creator to upload again. It moves to a cheap, cold storage tier (Chapter 11).

Memory code: "Original kept cold, renditions served hot, status in the database."