Design YouTube

Problem Statement & Context

YouTube is a global user-generated video platform: anyone can upload a clip, and within minutes that clip is transcoded into a ladder of resolutions and served from a CDN edge a few milliseconds from almost any viewer on Earth. The features are easy to state — upload, watch, search, recommend, comment. What makes the problem hard is scale. More than 500 hours of video are uploaded every minute, the stored catalog runs into the exabytes, and over 2 billion monthly users watch more total minutes than every broadcast television network combined. A design that works for a thousand videos collapses here — not because the features change, but because storage cost, encoding throughput, and delivery bandwidth come to dominate every decision.

It helps to see the system as two coupled machines with opposite personalities. The first is a media factory: it ingests a raw upload, fans it out across a transcoding farm, and emits dozens of renditions plus a streaming manifest. It is write-heavy, compute-bound, and tolerant of minute-scale latency. The second is a personalized TV guide: it indexes every title, caption, and engagement signal, then ranks billions of candidate videos into one home feed per user. It is read-heavy and latency-critical. The two share storage and metadata but pull in opposite directions, and most of the interesting trade-offs in this design live precisely on that seam.

The number to internalize first is the read/write asymmetry. For every upload there are on the order of a million views, so the architecture optimizes ruthlessly for reads: video bytes are written once to object storage and then served from edge caches, view counts are aggregated asynchronously rather than updated on the hot path, and metadata is denormalized into read-optimized stores. The classic failure is to increment a view counter synchronously in a SQL row — one viral video draws hundreds of thousands of concurrent viewers, and a synchronous counter turns that popularity into a hot-row meltdown that takes the whole table down.

Scope the conversation out loud. You cannot design all of YouTube in 45 minutes, so name your slice. A strong default: focus on the viewer path (upload → transcode → playback) and the discovery surface (search plus the recommendation feed); treat live streaming and the full Creator Studio as out of scope; and flag Content ID copyright matching, regional licensing, and YouTube Kids policy as real constraints you understand but will not deep-dive. Stating what you defer signals that you know the true surface area — it matters as much as stating what you build.

A few platform realities should shape the design, and they are worth surfacing early rather than discovering mid-interview:

• Reads dwarf writes by roughly 1,000,000:1, so CDN hit rate (target >90%), not origin capacity, sets the egress bill.
• Ingest is bursty — uploads spike around live events and product launches — so transcoding must be an elastic, embarrassingly parallel batch farm, not a fixed pool.
• Accounting must be exact-enough: creator payouts and ad billing depend on view and watch-time counts that are aggregated, deduplicated, and reconciled — never naively incremented.
• Policy is a pipeline stage, not an afterthought: Content ID fingerprint matching, per-region licensing blocks, and Kids-mode restrictions run inline on ingest and playback.
• Clients are heterogeneous: mobile-first viewers in India, Brazil, and Indonesia, lean-back TV apps (Roku, Fire TV), and offline downloads each impose distinct latency, UX, and DRM constraints.

What the interviewer is really testing is whether you reason from numbers to architecture rather than drawing boxes. They want to hear the chain of inference out loud: "500 hours/minute of ingest means transcoding is embarrassingly parallel, so I fan it across a worker farm"; "a million-to-one read ratio means the edge cache, not the database, is my scaling lever"; "viral hotspots mean view counts must be asynchronous and idempotent." Anchor every component to a measurable SLO — playback startup under roughly 2 seconds at p95, CDN hit rate above 90%, upload-to-watchable in single-digit minutes — and you will sound like an engineer who has operated the system, not one who has only read about it.

The sharpest failure story to keep ready is the viral-spike hot path: a single video jumps from hundreds to millions of concurrent viewers in minutes. A naive design melts at the view counter and the origin; the YouTube-grade answer absorbs the spike at the CDN edge, serves stale-but-fresh metadata from cache, and folds view counts through an asynchronous aggregation pipeline so the database never sees the stampede.