1Context and scope
Design a video platform where anyone can upload a video and anyone can watch it, at YouTube’s scale. Two very different systems share one product. The write side takes in large files, keeps them safe and turns each one into many streamable versions in the background. The read side starts playback in about a second for viewers everywhere and moves on the order of 100 Tbps of video, almost all of it from caches close to the viewer. Around both sit the parts that make it a product: video metadata, a personalised home feed, search, comments and view counts. The interview is about putting each workload on the right path, sizing it with numbers, and keeping playback working when caches go cold or a dependency slows down.
2Clarifying questions
- Which features are in scope: upload, playback, search, home feed, comments, view counts? Live streaming and Shorts?
- Upload, transcoding, playback, home feed, search, comments and view counts. Live streaming, Shorts feeds, ads and moderation are out of scope, though I will say where moderation and copyright checks hook into the upload pipeline.
- How big? Daily viewers, uploads and watch time?
- Plan for about 1 billion daily viewers (an assumption; YouTube reports over 2 billion logged-in monthly users), over a billion hours watched a day (YouTube, 2017) and more than 500 hours uploaded a minute (YouTube, 2019).
- Which clients and network conditions?
- Phones on mobile networks, browsers and TVs. Bandwidth varies from under 1 Mbps to over 25 Mbps and changes during a session, so playback must adapt per segment.
- How fast must playback start, and how fast must a new upload become watchable?
- Playback should start in about a second, with the API part well under 300 ms at p99. A new upload should be watchable at low resolution within minutes; higher resolutions and newer codecs can follow.
- How large can an upload be?
- Up to many gigabytes and many hours. That rules out single-request uploads: uploads must be chunked and resumable.
- How fresh and exact must view counts be?
- Approximately live, seconds to minutes behind, and correctable later. They must never lose an accepted event or count one twice, because creators are paid on them, and invalid traffic must be filtered.
- Global audience? Any data residency constraints?
- Global viewers served from caches near them, a few regions for the backend. Assume no residency constraints for this exercise.
- Is there a cost target?
- Yes: bandwidth and storage dominate the bill, so cache hit ratio, codec efficiency and how many renditions to keep are design decisions, not afterthoughts.
3Goals and non-goals
Goals
- Upload a video of any size from an unreliable connection, resuming where it stopped; the original is durable once the upload is acknowledged.
- Transcode each upload into an adaptive-bitrate ladder (from 144p up to the source resolution, in H.264 and newer codecs such as VP9 and AV1) in the background; the video becomes watchable when its first renditions are ready.
- Start playback fast and adapt quality to the viewer’s bandwidth: a manifest from the API, segments from a CDN.
- A personalised home feed and “up next” recommendations, ranked per viewer.
- Search by title, description, tags and channel, paginated.
- Comments on videos, and view and watch-time counts that are approximately live and never lose or double-count accepted events.
- Simulated slice: 2,500 requests a second (1,000 playback starts, 750 view events, 350 home feeds, 200 searches, 125 comments, 75 upload chunks); success at least 99.8%; p99 at most 300 ms for playback starts, 400 ms for home, 500 ms for search; a $16,000 monthly budget.
Non-goals
- Live streaming, Shorts-specific feeds, ads and monetisation.
- Copyright matching (Content ID) and content moderation, beyond saying where they hook into the upload pipeline.
- Video editing, captions generation and creator analytics dashboards.
- Multi-region active-active writes for metadata: one primary region per shard, with read replicas everywhere.
5Capacity estimate
| Quantity | Value | How |
|---|---|---|
| Simulated slice | 2,500 requests/s | 1,000 playback starts, 750 view events, 350 home feeds, 200 searches, 125 comments, 75 upload chunks |
| Playback starts (full scale) | ≈ 58,000/s on average | assumption: 1 billion daily viewers × 5 starts a day ÷ 86,400 s; the slice is about 1/60 of this |
| Playback starts at peak | ≈ 116,000/s | 2× the average (a planning assumption); a viral video spikes on top, which the simulation tests at 4× |
| Concurrent streams | ≈ 41.7 million | over a billion hours watched a day (YouTube, 2017) ÷ 24 hours |
| Video egress | ≈ 104 Tbps | 41.7 million streams × 2.5 Mbps average (an assumption for a mix of phones and TVs) |
| Cache-fill from origin | ≈ 5.2 Tbps at a 95% edge hit ratio | 5% × 104 Tbps; each point of hit ratio is worth about 1 Tbps |
| Uploads | 720,000 hours of video a day | more than 500 hours a minute (YouTube, 2019) × 1,440 minutes |
| Storage added a day | ≈ 4.3 PB logical, ≈ 13 PB with 3 copies | 2 GB an hour for originals (an assumption) = 1.44 PB, plus about 2× that for the rendition ladder in two codecs |
| Metadata cache | ≈ 200 GB | the hottest 10% of an assumed 1 billion videos × 2 KB each |
| View and watch-time events | ≈ 700,000/s | 41.7 million players × one batched event a minute |
| Reference design cost | ≈ $11,100 a month (budget $16,000) | the simulated slice: the CDN, encoder farm, watch-history writes and internet egress are the largest lines |
The rest of the doc
Non-functional requirements · API · Data model · The design · Deep dives · Key concepts · Alternatives considered · Failure modes and fixes · Interviewer follow-ups · Common mistakes · What a strong answer covers · Try it in the lab · Check yourself · Further reading
Unlock “YouTube: the full system design interview”
The full interview: clarifying questions, estimates, API, data model, the design, deep dives with trade-offs, follow-ups, common mistakes and a rubric. Unlocking it also unlocks the build problem in the lab. Paid once, on your account.