Design YouTube / Netflix

1. What is YouTube?

YouTube is a video-sharing platform where users upload, view, and share videos. Netflix is similar but focuses on premium, long-form content. The core engineering challenge is Streaming massive amounts of data with low latency to users with varying network conditions (3G to Fiber).

The Scale

  • Users: > 2 Billion active monthly users.
  • Uploads: 500 hours of video uploaded every minute.
  • Bandwidth: Accounts for ~15% of total global internet traffic.
  • Latency: Users expect instant playback (< 200ms start time).

2. Requirements & Goals

Functional Requirements

  • Upload Video: Users upload raw video files (MOV, MP4, AVI).
  • Watch Video: Users stream videos smoothly (no buffering).
  • Search: Find videos by title, description, or tags.
  • Stats: View counts, likes, and watch history.

Non-Functional Requirements

  • Low Latency: Minimize TTFB. Video must start playing immediately.
  • High Availability: Videos must always be playable. The system is Read-Heavy (1:1,000,000 ratio).
  • Scalability: Must handle viral videos (The Thundering Herd problem) without crashing.
  • Reliability: Uploads should be durable and never lost.

Try it yourself: Open a YouTube video. Right click ‘Stats for Nerds’. Watch the ‘Buffer Health’ and ‘Connection Speed’. Manually switch quality to 1080p and watch the buffer drop.

3. Capacity Estimation

This is a Bandwidth-Bound system.

Storage Estimation (Daily Ingestion)

  • Upload Rate: 500 hours of video / minute.
  • Raw Size: Assume 50MB per minute of raw HD video.
    • 500 hours × 60 mins × 50 MB = 1.5 TB / minute.
    • Daily Raw Ingestion: 1.5 TB × 1440 mins &approx; 2.1 PB / day.
  • Transcoded Storage: We store multiple resolutions (360p, 720p, 1080p, 4K).
    • Compression reduces size, but variants add up. Assume total storage &approx; 1 PB / day.
    • 5 Year Storage: 1 PB × 365 × 5 &approx; 1.8 Exabytes.

Bandwidth Estimation (Egress)

  • Daily Views: 1 Billion views.
  • Avg View Duration: 10 minutes.
  • Avg Bitrate: 2 Mbps (Mobile/Desktop mix).
  • Total Data: 1B views × 600s × 2 Mbps = 1.2 Exabits = 150 Petabytes / day.
  • Throughput: 150 PB / 86400s &approx; 1.74 TB/sec.
  • Cost: At $0.01 per GB (CDN pricing), this is $1.5 Million / day. We need our own CDNs (Open Connect / Google Global Cache).

4. System APIs

We need a separate API for Upload (Write) and Streaming (Read).

4.1 Upload API (Resumable)

POST /video/upload/init
Authorization: Bearer <token>

{
  "title": "My Cat Video",
  "description": "Funny cat jumping",
  "file_size": 104857600,
  "format": "mp4"
}

Response:

{
  "upload_id": "vid_999",
  "upload_url": "https://ingest.youtube.com/upload/vid_999"
}

4.2 Streaming API (HLS/DASH)

The client fetches the Manifest File which contains links to video chunks.

GET /video/stream/vid_999.m3u8

Response (m3u8):

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360
https://cdn.yt.com/vid_999/360p.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2500000,RESOLUTION=1280x720
https://cdn.yt.com/vid_999/720p.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
https://cdn.yt.com/vid_999/1080p.m3u8

4.3 Metadata API

GET /video/metadata?id=vid_999

Response:

{
  "title": "My Cat Video",
  "views": 150200,
  "likes": 5000,
  "uploader": "CatLover123"
}

5. Database Design

Metadata DB (Cassandra / Spanner)

We need high write throughput for stats (likes/views) and horizontal scalability.

  • Table Videos: video_id (PK), uploader_id, title, state (Processing, Ready).
  • Table Users: user_id (PK), email, name.
  • Table Comments: comment_id, video_id (Cluster Key), user_id, text.

Blob Storage (S3 / GCS)

  • Raw Bucket: Stores the original uploaded file.
  • Transcoded Bucket: Stores the processed chunks (.ts, .m4s) and manifests (.m3u8, .mpd).

6. High-Level Design

Video Streaming Pipeline Architecture.

System Architecture: Video Transcoding & Streaming
Upload Service | Transcoding DAG | CDN Distribution
Upload Flow
Processing (DAG)
Streaming Flow
Creator
Ingestion
Transcoding DAG
Global Distribution
Uploader
API Gateway
Upload Svc
Raw S3
Original File
DAG Coordinator
Workflow Manager
Splitter
Worker 1
Worker 2
Worker N
Parallel Encoding
Merger
Processed S3
.ts chunks
.m3u8 manifest
Multiple Res
CDN Edges
US East
EU West
Asia Pacific
Viewer
Upload Event Coordination Publish Stream
  1. Creator: Uploads video to Upload Service.
  2. Ingestion: Video is stored in S3 (Raw).
  3. Transcoding DAG: A complex DAG pipeline (Coordinator -> Splitter -> Workers) picks up the video.
  4. Distribution: Processed chunks are stored in S3 (Public) and cached on CDN Edges.
  5. Viewer: Requests video. Load Balancer directs them to the nearest CDN Edge.

7. Component Design (Deep Dive)

Video Encoding (The Transcoding DAG)

Raw video is too large and comes in random formats. We must standardize it. We use a Directed Acyclic Graph (DAG) (visualized in the Processing Zone) to parallelize the workflow:

  1. DAG Coordinator: Manages the workflow state.
  2. Splitter: Breaks the video into small chunks (GOP).
  3. Workers: Parallel nodes processing chunks for different resolutions.
  4. Merger: Combines processed chunks into a final manifest.

The pipeline steps:

  1. Validation: Check if the file is a valid video container.
  2. Metadata Extraction: Extract duration, bitrate, resolution.
  3. Splitting (GOP): Break the video into “Group of Pictures” or chunks (e.g., 4 seconds). This allows us to process a 1-hour movie on 1,000 servers in parallel.
  4. Transcoding: Convert each chunk into:
    • Resolutions: 360p, 480p, 720p, 1080p, 4K.
    • Codecs: H.264 (Compatible), VP9 (Efficient), AV1 (Next-Gen).
    • Containers: HLS (.ts), DASH (.m4s).
  5. Thumbnail: Generate preview images.
  6. Merge: Create the Manifest File (.m3u8) which acts as an index for the player.

Adaptive Bitrate Streaming (ABR)

This is the “magic” that prevents buffering.

  • Server Side: We don’t stream a single file. We host thousands of tiny 4-second chunks for every resolution.
  • Client Side: The player logic is “thick”.
    1. Measure Bandwidth: How fast did the last chunk download?
    2. Check Buffer: Do I have 30 seconds buffered or 2 seconds?
    3. Decision:
      • Network Fast + Buffer Full -> Request 1080p.
      • Network Slow OR Buffer Low -> Panic! Switch to 360p to keep playing.

CDN Architecture (Edge vs Origin)

Visualized in the Global Distribution zone:

  1. CDN Edges: Located in the ISP (Comcast, Verizon). Serves 95% of traffic.
  2. Origin Shield: A mid-tier cache. If Edge misses, it hits Shield. Shield aggregates requests from multiple Edges and fetches from Origin once.
  3. Anycast DNS: Both us-east and us-west users resolve video.youtube.com to 1.2.3.4. BGP routing directs packets to the physically closest server.

8. Requirements Traceability

Requirement Design Decision Justification
Low Latency CDN / Edge Caching Serve video from a server physically close to the user (< 20ms RTT).
No Buffering Adaptive Bitrate (ABR) Dynamic quality switching prevents playback stalls during network dips.
Throughput Parallel Transcoding DAG Process hours of video in minutes by using 1000s of workers.
Scalability Pre-Signed URLs + S3 Decouples authentication from data delivery. S3 scales indefinitely.
Rights DRM (Widevine/FairPlay) Encrypts content chunks to prevent piracy.

9. Observability & Metrics

For video, Client-Side Metrics (QoE) are more important than Server-Side Metrics.

Client-Side (QoE)

  • Start Time: Time from click to first frame. Target < 200ms.
  • Rebuffer Ratio: % of time spent buffering. Target < 0.5%.
  • Bitrate Switch Count: Too many switches annoy users.

Server-Side

  • Cache Hit Ratio: Target > 98% at Edge. Lower means higher Origin cost.
  • Transcoding Time: Time to make a video available after upload.

10. Deployment Strategy

Shadow Traffic (Transcoding)

When upgrading the encoding algorithm (e.g., ffmpeg v4 to v5):

  1. Route 1% of uploads to both v4 and v5 pipelines.
  2. Compare Output Quality (VMAF score) and Processing Time.
  3. Discard v5 output.
  4. If v5 is better, promote to production.

Canary Deployment (CDN)

Update CDN firmware region by region.

  • Start with a small ISP in a non-peak timezone.
  • Monitor Rebuffer Ratio.
  • Rollback if latency spikes.

11. Interview Gauntlet

Rapid Fire Questions

  1. Why use UDP/QUIC instead of TCP? TCP Head-of-Line blocking causes stuttering if one packet is lost. QUIC (HTTP/3) handles packet loss better for streams.
  2. How do you estimate CDN costs? $0.01/GB. 1B views * 1GB/view = 1 Exabyte/day. That’s expensive! We need to build our own ISP-embedded caches (Open Connect).
  3. How does Live Streaming differ from VOD? Live needs Low Latency (CMAF chunks). We cannot buffer 30s ahead. We use chunked transfer encoding and smaller GOP sizes (1s).
  4. What is a ‘Manifest File’? A text file (.m3u8) listing the URLs of all video chunks and available resolutions. The player downloads this first.
  5. How do you protect paid content? Signed URLs + DRM. The URL expires in 1 hour. The content is encrypted with a key only the License Server has.

12. Interactive Decision Visualizer: Adaptive Bitrate Streaming

This simulator puts you in charge of the Player Logic.

  • Scenario: You are watching a movie. Your network is fluctuating.
  • Goal: Keep the video playing (don’t let the Buffer hit 0) while maximizing Quality.
  • Observe: When bandwidth drops (Red), the player automatically switches to Low Quality (360p) to fill the buffer faster.
0.5 Mbps 4.0 Mbps 10 Mbps
● Low (0-2): Forces 360p
● Med (2-5): Supports 720p
● High (5+): Supports 1080p
BUFFER
5.0s
QUALITY
720p
BITRATE COST
2.0 Mbps
DL SPEED
0.5 MB/s
CINEMA
HD
> System Initialized. Stream starting...

13. Summary (Whiteboard)

Scale & Bandwidth

  • 15% of Internet Traffic (Exabytes)
  • Bandwidth is the bottleneck (not CPU)
  • Cost = $0.01/GB. Must use Edge Caches.

Streaming Tech

  • DAG Pipeline: Parallelize encoding
  • ABR: Client-side quality switching
  • GOP: Keyframe interval (Chunk size)
  • CDN: Edge -> Shield -> Origin

Protocols

  • HLS/DASH: HTTP-based streaming
  • UDP/QUIC: Avoids HOL Blocking
  • Anycast DNS: Route to nearest PoP

Reliability

  • DRM: License server interaction
  • Thundering Herd: Viral videos hit CDN hard
  • SLA: Availability < Consistency (for Uploads)