Design YouTube the way a senior system-design interview expects: resumable uploads and a transcoding pipeline, adaptive playback through a CDN, a sharded metadata store behind a cache, two-stage recommendations, search, comments and view counting, then survive a viral video, a cold CDN, a cold cache, an upload surge, a slow ranker, a stream outage and a DDoS attack.
Unlock it once for 25 credits; everything inside it is free (runs, changes, Submit, results, hints). Sign in with Google to start; new accounts get free credits.
What it must do
Upload a video with a resumable, chunked upload; store the original and transcode it in the background into an adaptive-bitrate ladder (144p to 4K, in more than one codec).
Start playback fast: video metadata and the stream manifest from the API, the segments from a CDN close to the viewer, adapting quality to the viewer’s bandwidth.
Show a personalised home feed: candidate videos from several sources, ranked by a learned model, with a fallback when the ranker is slow.
Search videos by title, description and tags, a page at a time.
Post comments on a video.
Count views and watch time from player events, asynchronously, without losing or double-counting them.
Scale
This simulation runs a scaled-down slice of the API traffic: 2,500 requests a second, of which 1,000 playback starts, 750 view events, 350 home feeds, 200 searches, 125 comments and 75 upload chunks.
A playback start asks the edge for the manifest and first segments: the CDN answers about 90%, and misses go to a playback origin that builds the manifest from the video’s metadata and reads segments from object storage. Home feeds and search results read the same metadata (titles, thumbnails, durations) through a cache that answers about 95% of reads.
Uploads arrive in chunks; about one chunk in ten is a video’s final chunk, which writes the metadata row and queues the transcode (about 7.5 transcode jobs a second).
The full-scale numbers in the estimates assume about 1 billion daily viewers (YouTube reports over 2 billion logged-in monthly users), more than 500 hours of video uploaded a minute (YouTube, 2019) and over a billion hours watched a day (YouTube, 2017).
Popularity is very skewed: a small share of videos gets most views, and one viral video can multiply traffic several times within minutes.
Request types to route: watch (40%, read), view (30%, write), home (14%, read), search (8%, read), comment (5%, write), upload (3%, write). Budget: $16,000 a month.
Estimate first
Playback starts a second, on average, at full scale (starts/s)
Playback starts a second at the daily peak (assume 2× the average) (starts/s)
Video egress at full scale, at an average of 2.5 Mbps a stream (Tbps)
Cache-fill traffic from origin if the edge hit ratio is 95% (Tbps)
Raw video storage added a day, with renditions and 3 copies (PB)
Metadata cache memory for the hottest 10% of 1 billion videos at 2 KB each (GB)
View and watch-time events a second at full scale, one batched event per player a minute (events/s)
Monthly cloud cost of the reference design (the simulated slice) (USD)
The test cases
You start from an empty canvas. When you run the tests, each one simulates your design with its own traffic and failures:
Test
What it does
Passes when
Normal day
The normal day: the traffic in the brief, nothing broken.
Success ≥ 99.8%; p99 latency ≤ 300 ms (watch); p99 latency ≤ 400 ms (home); p99 latency ≤ 500 ms (search); Success ≥ 99.8% (upload); Success ≥ 99.8% (view)
A video goes viral
At 5 s a video goes viral and the app sends a push notification: all traffic quadruples for 8 s, almost all of it people starting playback.
Success ≥ 99%; p99 latency ≤ 600 ms (watch); p99 latency ≤ 800 ms (home)
The CDN goes cold
At 5 s the video CDN is emptied, as after a bad config push or a new edge site coming online: every playback start misses at the edge and goes to your origin until the edge warms up again (about 30 s).
Success ≥ 99%; p99 latency ≤ 800 ms (watch)
The metadata cache is flushed
At 5 s the video metadata cache is emptied, as after a restart or a bad deploy: every metadata read (manifests at the origin, titles and thumbnails on home feeds and search results) goes to the database until the cache warms up again.
Success ≥ 99%; p99 latency ≤ 800 ms (watch)
Upload surge: the encoder farm falls behind
At 5 s a surge of uploads (a big event ends and everyone posts their clips) saturates the encoder farm: every encode takes 10× longer for 10 s.
At 5 s the recommendation ranker answers 10× slower for 8 s, as after a bad model push or a lost accelerator pool.
Success ≥ 99% (home); p99 latency ≤ 800 ms (home)
The view event stream goes down
At 5 s the view event stream crashes; it comes back after its restart time (10 s unless you set one). While this test runs, brokers redeliver unacknowledged messages after 5 s and 0.2% of acknowledgements are lost, as in production: only idempotent consumers avoid duplicates.
No lost events; No duplicate side effects; Success ≥ 99% (view)
DDoS attack
At 5 s 30,000 requests a second of flood traffic arrive for 10 s, alongside real users.
The normal day's design must cost at most $16,000 a month.
Cost ≤ $16,000/month
Must include
DDoS protection at the edge. A site this visible is attacked all the time: floods must be absorbed before anything spends compute on them.
A CDN for video segments. Video bytes are almost all of the traffic (about 100 Tbps at full scale). Popular segments must be served from caches close to viewers, ideally inside their ISPs, not from your data centers.
Object storage for originals and renditions. Originals and every rendition’s segments are large immutable blobs, petabytes a day of them: they belong in object storage, which is the CDN’s origin.
A transcoding pipeline. Every upload must be encoded into a ladder of resolutions and codecs before it can stream adaptively; encoding is slow and heavy, so it runs on an encoder farm fed by a queue.
A sharded metadata database (behind a cache). Titles, channels, rendition lists and privacy settings are small relational records read on every playback start: shard them by video id (as Vitess shards MySQL) and keep the hot ones in a cache.
A recommendation ranker. The home feed is ranked per viewer: a learned model scores hundreds of candidates on every load.
An event stream for views. View and watch-time events are the largest write stream in the system; a durable, replayable log lets counters, history and the recommender consume them at their own pace.