Product SystemsHardavailable

Design YouTube / Video Platform

Architect a video platform from upload and transcoding pipelines to adaptive bitrate streaming, recommendation engines, and massive daily view counts.

One-session flow: requirements -> scale math -> APIs -> media pipeline -> recommendations -> global scale
Current section
Video Platform Architecture
tier-1
Current step
1 / 3
Two critical paths
Interview angle
Start with the two-path architecture, then move from requirements to the subsystems that actually dominate cost, latency, and product quality.
Sections

Interview agenda

11 guided sections
System Design · Video Platform

Video Platform Architecture

intro
A strong answer starts with the creator upload path and the viewer playback path. Everything else hangs off these two flows.
Flow diagram

YouTube overview

Uploads: heavy processingPlayback: edge first
Start with the full platform map, then zoom into the subsystems that are interview differentiators.
Creator
source
creator
Uploads raw video
Upload Service
accepts chunks
upload
Resumable chunk ingestion
Transcoder
async
transcode
FFmpeg / GPU fan-out
Blob Storage
durable
storage
Origin renditions + segments
CDN Edge
read path
cdn
Serves manifests and segments
Metadata DB
catalog
meta
Video rows + publish state
Search Index
discovery
search
Text retrieval + filtering
Rec Engine
watch-next
rec
Candidate gen + ranking
creator → upload
active
resumable chunks
upload → transcode
muted
assembly then async job
transcode → storage
muted
multiple renditions
storage → cdn
muted
manifest + segments
upload → meta
attenuated
create video row
meta → search
attenuated
index metadata
meta → rec
attenuated
feature updates
Table view

Video Platform Architecture

Frame the upload path and the watch path before diving into detailed trade-offs.
Read / write
100:1+
—
Upload trigger
one ingest
—
Watch fan-out
millions
—
Upload path
creator -> upload -> transcode -> storage
CPU/GPU heavy, asynchronous, and failure-prone around ingest and encoding.
Watch path
manifest -> segments -> CDN edge
Read-heavy, latency-sensitive, and ideal for cache-friendly static segment delivery.
Why this matters
Upload is low QPS but heavy compute because every video fans out into many renditions.
Interview cue
Watch is extremely read-heavy, so CDN, caching, and recommendation quality dominate the user experience.
Control State
Section
Architecture
Tier
tier-1
Snapshot
Two critical paths
Progress
1/3
creator -> ingest -> transcode -> origin -> edge -> player•Step 1/3
What You Will Learn
Break Design YouTube / Video Platform into core user flows, write paths, read paths, and offline/background work.
Model the dominant data entities, indexing strategy, and hot-path caches before tuning secondary features.
Identify where realtime updates, fan-out, ranking, or matching logic becomes the main scaling constraint.
Plan abuse prevention, reconciliation, and operational visibility alongside the happy path.
Design Trade-offs
What is the dominant read/write path that makes Design YouTube / Video Platform hard at scale?
Where do you need async boundaries, queues, or precomputation instead of synchronous work?
Which data becomes hottest first, and how do you partition or cache it safely?
What correctness risks remain after the first scalable design is in place?