Design YouTube

YouTube stats (2020): 2B MAU, 5B videos watched/day, 50M creators, $15.1B ad revenue, 37% of mobile internet traffic, 80 languages.

Step 1 of 4: Understand the problem and establish design scope #

Goal: lock in requirements and scale numbers.

Requirements:

1. Core features: upload videos and watch videos
2. Clients: mobile apps, web browsers, smart TV
3. 5 million DAU, avg 30 min/day
4. International users supported
5. Accepts most video resolutions and formats
6. Encryption required
7. Max video size: 1 GB
8. Leverage existing cloud infrastructure (CDN, blob storage)

Back of the envelope estimation:

1. 5M DAU × 5 videos/day watched
2. 10% of users upload 1 video/day
3. Avg video size: 300 MB
4. Daily storage: 5M × 10% × 300 MB = 150 TB
5. CDN cost (US, $0.02/GB):5M\times 5\times 0.3GB\times$0.02 = $150,000/day

Step 2 of 4: Propose high-level design and get buy-in #

Goal: leverage the cloud: CDN + blob storage (building from scratch is too complex; even Netflix uses AWS, Facebook uses Akamai).

Three components: Client → CDN (video streaming) + API servers (everything else).

Video uploading flow #

Components:

1. Load balancer: distributes requests to API servers
2. API servers: all non-streaming requests
3. Metadata DB: video metadata (sharded, replicated)
4. Metadata cache: video metadata + user objects
5. Original storage: blob storage for source videos
6. Transcoding servers: convert videos to different formats/bitrates
7. Transcoded storage: blob storage for processed videos
8. CDN: caches and serves videos
9. Completion queue + Completion handler: message queue tracking transcoding completion; workers update metadata cache/DB

Two parallel processes:

Flow A: Upload actual video:

1. Video uploaded to original storage → 2. Transcoding servers fetch and transcode → 3a. Transcoded videos → transcoded storage → CDN; 3b. Completion events → completion queue → completion handler updates metadata DB/cache → 4. API servers notify client

Flow B: Update metadata: client sends metadata (filename, size, format) in parallel; API servers update metadata cache + DB.

Video streaming flow #

Streaming protocol options: MPEG-DASH, Apple HLS, Microsoft Smooth Streaming, Adobe HDS. Videos streamed directly from the CDN edge server closest to the user → minimal latency.

Step 3 of 4: Design deep dive #

Goal: transcoding pipeline (DAG), optimizations, safety, cost.

Video transcoding #

Why transcode:

1. Raw video is huge: 1hr HD at 60fps → hundreds of GB
2. Device/browser compatibility requires multiple formats
3. Adaptive bitrate: high-res for high bandwidth, low-res for low bandwidth
4. Network conditions change → auto/manual quality switching

Video format anatomy:

1. Container: file extension (.avi, .mov, .mp4): wraps video, audio, metadata
2. Codecs: compression algorithms: H.264, VP9, HEVC

Directed Acyclic Graph (DAG) model #

Transcoding is computationally expensive. DAG defines tasks in stages for sequential/parallel execution (inspired by Facebook's SVE).

Tasks:

1. Inspection: quality check, malformed detection
2. Video encodings: different resolutions, codecs, bitrates

3. Thumbnail: user-uploaded or auto-generated
4. Watermark: identifying image overlay

Video transcoding architecture #

Six components:

Preprocessor:

1. Video splitting: split into GOP (Group of Pictures) chunks: each a few seconds, independently playable
2. Handles old clients that can't split videos
3. DAG generation: from client programmer config files

4. Cache data: store GOPs and metadata in temporary storage for retry on failure

DAG scheduler:

Splits DAG into task stages, puts them in the resource manager's task queue.

Example. Stage 1: video, audio, metadata split. Stage 2: video encoding + thumbnail from video; audio encoding from audio.

Resource manager:

Three queues: Task queue (priority), Worker queue (worker utilization), Running queue (active task/worker bindings). Task scheduler picks the optimal task+worker, instructs execution.

Task workers:

Run DAG-defined tasks. Different workers for different task types.

Temporary storage:

Multiple storage types: metadata in memory (small, frequent access); video/audio in blob storage. Freed after processing completes.

Encoded video:

Final output, e.g. funny_720p.mp4.

System optimizations #

Speed: Parallelize video uploading: split video into GOP chunks client-side. Enables fast resumable uploads.

Speed: Upload centers close to users: multiple upload centers globally via CDN.

Speed: Parallelism everywhere: introduce message queues between processing stages to decouple modules. The encoding module doesn't wait for the download module's output: it processes events from the queue in parallel.

Safety: Pre-signed upload URL:

1. Client requests a pre-signed URL from the API server → 2. API server returns URL → 3. Client uploads directly. Only authorized users can upload to the correct location (Amazon S3: "pre-signed URL"; Azure: "Shared Access Signature")

Safety: Protect videos:

1. DRM: Apple FairPlay, Google Widevine, Microsoft PlayReady
2. AES encryption: decrypt on playback; only authorized users
3. Visual watermarking: company logo/name overlay

Cost-saving:

YouTube videos follow a long-tail distribution: few popular, many rarely viewed.

1. Only serve popular videos from CDN; rest from high-capacity video servers

2. Fewer encoded versions for less popular content; encode short videos on-demand
3. Don't distribute region-specific popular videos globally
4. Build your own CDN + partner with ISPs (Netflix model)

Error handling #

Step 4 of 4: Wrap up #

Additional talking points:

1. Scale API tier: stateless → easy horizontal scaling
2. Scale database: replication and sharding
3. Live streaming: higher latency requirements, lower parallelism needs, different error handling (no slow retries)
4. Video takedowns: copyright violations, pornography: system detection on upload + user flagging