System Design HLD Example: Video Streaming (YouTube/Netflix)

Scenario context

A video streaming platform is a two-sided architectural beast: a batch-oriented transcoding pipeline that converts raw uploads into multi-resolution segments, and a real-time global delivery network that serves those segments via CDNs. The technical linchpin is Adaptive Bitrate Streaming (ABR), which enables the client player to seamlessly switch quality based on network fluctuations, ensuring a buffer-f…

This walkthrough focuses on The "Game of Thrones" Crash.

Before making a design choice, clarify:

• Millions of people simultaneously hit "Play" on the season finale of the world's most popular show.
• For the first five minutes, everything is fine.
• Then, the Twitter complaints start: "Buffering...", "Pixelated mess!", "Server error 500." Behind the scenes, the origin servers are melting.

Concepts in play: caching, system-design-hld-architectures, event-driven-architecture, stack-and-queue-data-structures

Stage 1 — Video Streaming: Use Cases & Requirements

• Actors & Journeys Content Creator: Uploads high-quality raw video files (often $ 100$ GB).
• They require a reliable, resumable upload path.
• Viewer: Consumes content across diverse devices (4K TV, 720p Laptop, 360p Smartphone).
• They require "instant-on" playback and no buffering.

Observable outcome: They require "instant-on" playback and no buffering.

Stage 2 — Foundations: How Video Streaming Actually Works

• Unlike a simple file download where you wait for the whole file to arrive, modern streaming uses Segmented Delivery .
• The baseline architecture involves three main pillars: 1.
• The Bitrate Ladder: A single video is converted into multiple files with different resolutions and bitrates.
• Segmentation: Each of these files is sliced into 2-10 second "chunks" or "segments." 3.

Observable outcome: Segmentation: Each of these files is sliced into 2-10 second "chunks" or "segments." 3.

Stage 3 — The Mechanics of Adaptive Bitrate (ABR)

• The mechanism of quality switching happens entirely on the Client Side .
• HLS (HTTP Live Streaming): Developed by Apple, it uses .ts segments and is the standard for iOS/Safari.
• DASH (Dynamic Adaptive Streaming over HTTP): An international standard that is more flexible and widely used on Android and Smart TVs.
• The Switching Logic: The player maintains a "Buffer Health" counter (e.g., 20 seconds of video pre-downloaded).

Observable outcome: The Switching Logic: The player maintains a "Buffer Health" counter (e.g., 20 seconds of video pre-downloaded).

Stage 4 — Estimations & Design Goals

• The Math of YouTube-Scale Ingest Volume: 500 hours/min = 30,000 hours/hour.
• Raw Storage: 30,000 hours $\times$ 5 GB/hour (high-bitrate 1080p) = 150 TB/hour .
• Transcoding Expansion: Each video is transcoded into $\approx 6$ resolutions.
• Total storage after processing $\approx 3\times$ the raw size.

Observable outcome: Total storage after processing $\approx 3\times$ the raw size.

Stage 5 — High-Level Design: The Twin Pipeline Architecture

• The architecture is split into a Write Path (Ingestion & Processing) and a Read Path (Discovery & Delivery).
• The architecture divides cleanly into a Write Path and a Read Path.
• On the Write Path, a creator's raw upload flows through a Load Balancer into the Upload Service, which stores the raw file in S3 and publishes a transcoding job to Kafka.
• A pool of Transcoding Workers consumes these jobs, producing multi-resolution segments stored in a separate S3 bucket.

graph TD
    Creator -->|Upload| LB[Load Balancer]
    LB --> US[Upload Service]
    US --> Raw[(Raw Store: S3)]
    Raw --> MQ[Message Queue: Kafka]
    MQ --> TW[Transcoding Workers]
    TW --> Segs[(Segment Store: S3)]

    Segs --> OS[Origin Shield]
    OS --> CDN[Global CDN Nodes]
    Viewer -->|Metadata| API[API Gateway]
    Viewer -->|Stream| CDN
    API --> DB[(Metadata DB: Postgres)]
    API --> Cache[(Redis Cache)]

Observable outcome: A pool of Transcoding Workers consumes these jobs, producing multi-resolution segments stored in a separate S3 bucket.

Stage 6 — Deep Dive: The Transcoding DAG and the Origin Shield Thundering-Herd Fix

• The transcoding pipeline is the most computationally intensive component in a video platform.
• A naive implementation assigns a single worker to transcode an entire 1-hour video into 6 resolutions sequentially — a process that could take 6 or more hours on a single machine.
• Production systems break this into a Directed Acyclic Graph (DAG) of parallel jobs .
• Each uploaded video is first split into 1-minute raw chunks at the Upload Service.

graph TD
    Upload[Raw Video Upload] --> Split[Chunk Splitter: 1-min segments]
    Split --> Kafka[Kafka: video.transcoding.jobs]
    Kafka --> W1[Worker: 360p Encoding]
    Kafka --> W2[Worker: 720p Encoding]
    Kafka --> W3[Worker: 1080p Encoding]
    Kafka --> W4[Worker: 4K Encoding]
    W1 --> Merge[Manifest Builder]
    W2 --> Merge
    W3 --> Merge
    W4 --> Merge
    Merge --> S3[Segment Store: S3]

Observable outcome: Each uploaded video is first split into 1-minute raw chunks at the Upload Service.

End-to-end outcome

Millions of people simultaneously hit "Play" on the season finale of the world's most popular show.

Alternatives considered

The source focuses on one primary design. A second architecture is not compared, so no alternative is invented here.

Failure and degraded modes

The Trade-offs That Define Video Platform Architecture

• Detection: DASH: HLS is Apple's proprietary standard, required for iOS and Safari.
• User or operator impact: DASH: HLS is Apple's proprietary standard, required for iOS and Safari.