Large-Scale Products

Design a Video Streaming Platform (YouTube)

Watch: "System Design Interview: Design YouTube w/ a Ex-Meta Staff Engineer" — Hello Interview

In simple words

A long film is cut into short clips, each prepared in several qualities. Your player downloads clip after clip from a shop near you, picking a lower quality clip when your internet slows down, so the film keeps playing instead of freezing.

Problem Statement

Design a video platform like YouTube: creators upload videos, the platform processes them into streamable formats, and viewers around the world watch with quick start times and smooth playback on any device and network. The core challenges are the processing pipeline and delivering enormous bandwidth cheaply.

Functional Requirements

Upload a video (up to several GB) with title and description.
Watch videos with adaptive quality (switches with network speed).
Video page with metadata, view counts and likes.
Out of scope: recommendations (mention), comments, live streaming, monetisation.

Non-Functional Requirements

Fast start and no buffering: first frame in about a second or two; rebuffering rare.
High availability for playback; uploads can take minutes to process.
Durability: an uploaded video is never lost.
Scale: 1B views/day, 500K uploads/day.

Uploads:  500K/day x 300 MB avg        = 150 TB/day of raw video
          + transcoded renditions (all together roughly the size of the original)
          -> ~100+ PB/year before replication: object storage, lifecycle tiers
Views:    1B/day                       ~ 12K video starts/s on average
Watching: 1B x 5 min = 5B min/day / 1,440 min ~ 3.5M concurrent viewers (avg)
Egress:   3.5M x ~3 Mbps               ~ 10 Tbps average, several times that at peak
          -> only possible with a CDN (and caches inside ISPs)

Core Entities

Video: id, owner_id, title, description, status (UPLOADING/PROCESSING/READY/FAILED), duration.
Rendition: video_id, resolution, bitrate, codec, manifest and segment locations.
Upload session: multipart upload state.
View / Like counters.

API Design

POST /v1/videos { title, description, size }      -> { video_id, upload_urls[] (pre-signed, multipart) }
POST /v1/videos/{id}/complete                      -> 202 (start processing)
GET  /v1/videos/{id}  -> { title, status, manifest_url: "https://cdn.../v/{id}/master.m3u8", views }
POST /v1/videos/{id}/views                         -> 204 (batched client beacons)

High-Level Design (HLD)

Videos are split, transcoded in parallel into several qualities, and streamed segment by segment from the CDN.

UPLOAD + PROCESSING
creator -> API (metadata DB: status=UPLOADING) -> pre-signed multipart URLs
creator == bytes ==> object storage (raw bucket)
object created event -> [ queue ] -> processing DAG:
     split into chunks (e.g. 4-10 s at keyframes)
       -> parallel transcode each chunk x each rendition (240p ... 4K, H.264/VP9/AV1)
       -> package into HLS/DASH segments + manifests
       -> thumbnails, content checks (copyright, safety)
     -> processed bucket; metadata status=READY

PLAYBACK
viewer -> API: video page + manifest URL
player -> CDN: master manifest -> picks rendition by bandwidth
        -> segments seg_001.ts, seg_002.ts ... (cache hits at the edge)
CDN miss -> origin shield -> processed bucket

Low-Level Design (LLD)

The player measures its bandwidth each segment and switches playlists between segments instead of stalling.

Adaptive bitrate streaming (HLS/DASH)

master.m3u8
  #EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360
  360p/index.m3u8
  #EXT-X-STREAM-INF:BANDWIDTH=2800000,RESOLUTION=1280x720
  720p/index.m3u8
  #EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
  1080p/index.m3u8

720p/index.m3u8 -> list of ~4-6 s segments
The player measures download speed and buffer level every segment and
switches renditions between segments: no stall, just a quality change.

Because everything is plain HTTP files, any CDN can cache it; the "server" is just static files.

Processing pipeline details

Chunked, parallel transcoding turns a 1-hour job into minutes; each task is idempotent (same input chunk + preset → same output key), so failed tasks just rerun.
A workflow orchestrator tracks the DAG per video and marks it READY only when required renditions exist (low resolutions first, so a video can go live before 4K is done).
Popular videos can be re-encoded with more expensive codecs (AV1) later, since they're watched enough to repay the compute.

Data model and counters

videos(video_id PK, owner_id, title, description, status, duration, created_at)
renditions(video_id, rendition, codec, bitrate, manifest_key, PRIMARY KEY(video_id, rendition))
views: client beacons -> stream -> aggregated per minute -> counter store
       (approximate, eventually consistent; exact dedupe of bots done offline)

CDN strategy

Long cache lifetimes for segments (they never change); short for manifests of processing videos.
Pre-warm edges for videos expected to go viral (a big creator's new upload).
Long-tail videos (rarely watched) are served from regional caches/origin; the head is served from edges.

Follow-up Questions

How do you make the video start fast?: Start with a low rendition and short first segments, put the first segments of popular videos in edge caches, keep the manifest small, and prefetch the next segment while playing.
Upload fails at 80% of a 4 GB file. Now what?: Multipart upload: parts that completed are kept; the client retries only missing parts and then completes the upload. The upload session tracks which parts are done.
How would you add live streaming?: Ingest (RTMP/SRT/WebRTC) to regional ingest servers, transcode in real time into short segments (1–2 s, or low-latency HLS), push to CDN continuously; latency and real-time transcoding capacity become the main constraints.