System Design · Design Question

Design YouTube

Video upload, transcoding, storage, and streaming via CDN — the interview path from phone camera to smooth playback.

1. Requirements

Functional

Upload videos; process into multiple bitrates/resolutions.
Stream with adaptive bitrate (HLS/DASH); thumbnails and metadata.
View counts (approximate OK); watch history optional later.

Non-functional

Low startup time; smooth ABR under varying bandwidth.
Huge storage and egress; CDN mandatory; resumable uploads.
Processing async — upload returns quickly; status becomes READY later.

Estimation snippet

Uploads: 5M videos/day * 100MB avg raw ≈ 500 TB/day ingest (order-of-magnitude) Watch: 1B views/day; avg 50MB streamed via CDN → enormous egress (CDN, not origin) Transcode: each video → several renditions → CPU/GPU worker fleet on queue depth Metadata DB: tiny vs blob store; never put video bytes in SQL

Scope: upload + watch; skip live streaming and comments in first pass Ask: max length, allowed formats, DRM needs?

2. API

POST /v1/videos/upload-session → { uploadUrl, videoId } PUT uploadUrl (resumable chunked upload to object store) POST /v1/videos/{id}/complete { title, description } GET /v1/videos/{id} metadata + playback manifests GET /v1/videos/{id}/play.m3u8 (or CDN URL)

3. Data model

videos(video_id, user_id, title, status, duration, created_at) assets(video_id, rendition, codec, storage_path, bitrate) thumbnails(video_id, url, ts_offset) views_approx(video_id, count) -- async aggregation

4. High-level design

Uploader → API → resumable upload → Object Store (raw) | enqueue Transcode Job v Transcode Workers (ffmpeg fleet) | write renditions + HLS segments → Object Store | update metadata status=READY | Viewer → App → metadata API → CDN → edge segments (origin = object store)

5. Deep dive — processing pipeline

Validate file; virus/malware scan optional queue.
Probe duration/codec; reject unsupported.
Generate ladder: 360p/720p/1080p… + audio.
Package HLS/DASH segments; create master playlist.
Extract thumbnails; maybe preview sprites.

Transcoding is CPU/GPU heavy — scale workers on queue depth; never do it inline in the upload request.

6. Playback and CDN

Player fetches master.m3u8 → picks bitrate by bandwidth Segments cached at CDN edges with long TTL (immutable paths) Hot videos stay warm globally; cold videos may miss → origin

Signed URLs for private/unlisted videos.
Origin shield to protect object store on sudden virality.

7. Scaling storage & cost

Raw + multiple renditions ≈ several times original size.
Lifecycle: delete raw after processing, or keep for re-encode.
Cold storage classes for rarely watched content.

8. Views and recommendations (brief)

Count views asynchronously (client beacon → queue → aggregate). Recommendations are a separate system (candidate generation + rank); mention but do not boil the ocean unless asked.

9. Failure cases

Transcode fail → retry; mark FAILED; notify user.
Partial upload → resumable protocol; GC incomplete after TTL.
CDN poison file → versioned paths + purge.

10. Adaptive bitrate details

The player monitors buffer health and bandwidth estimates, switching renditions at segment boundaries. Keep segment duration short enough for quick switches (e.g. 2–6s) but not so short that request overhead explodes.

master.m3u8 → 360p.m3u8 → seg0.ts seg1.ts ... → 720p.m3u8 → seg0.ts seg1.ts ... → 1080p.m3u8 ...

11. Hot vs cold video

Viral video: CDN hit ratio high; origin shield protects storage.
Long-tail: more origin pulls; cheaper storage class OK.
Pre-warm CDN for known big premieres when product can predict.

Quick revision

Resumable upload to object store; process async.
Transcode ladder + HLS/DASH segments for ABR playback.
CDN in front of segments; signed URLs for private content.
Metadata DB small; blobs huge — never store video in SQL.
Scale workers on queue lag; GPU optional.
View counts via async aggregation.
Lifecycle policies control storage cost.