Design YouTube

Problem statement

Design a user-generated video platform where creators upload videos of arbitrary length and codec, the platform transcodes each upload into a multi-bitrate ladder, stores it durably, delivers it to a global audience with adaptive bitrate streaming, helps billions of viewers discover what to watch next through search and recommendation, supports channels, subscriptions, comments and notifications, enforces copyright and safety policy at upload velocity, and monetizes playback through ad insertion with creator revenue sharing.

This is not an object-storage problem with a player bolted on. Three properties make it distinctive. First, the write path is expensive and asynchronous: one uploaded hour of video fans out into eight or more rendition encodes, thumbnail sprites, caption tracks, fingerprint signatures, and search documents, and none of that may block the creator's upload acknowledgement. Second, the read path is a continuous media stream: a single viewer generates one segment request every two to four seconds for the entire session, so playback concurrency — not page QPS — is the dominant load. Third, demand is brutally skewed: a small fraction of videos carries most of the bytes, and a viral upload can jump from zero to millions of concurrent viewers inside minutes, which means cache hierarchy and hot-key design are first-class architecture, not optimization trivia.

Public operating baseline versus design assumptions

Public figures anchor the category. YouTube reports more than 2.7 billion monthly logged-in users, more than one billion hours watched per day, roughly 500 hours of video uploaded per minute, and on the order of 70 billion Shorts views per day; Alphabet reported YouTube advertising revenue of about 36.1 billion dollars in 2024. YouTube has also publicly stated that around 70 percent of watch time comes from recommendations. These are cited company figures used for context. For capacity planning this answer explicitly assumes a mature platform with 450 million daily active users, an average concurrency derived from one billion watch-hours per day (about 42 million simultaneous streams), a 1.8x peak multiplier (about 75 million concurrent streams), 9 billion play starts per day including short-form, 12 million upload sessions per day, and 2 billion search queries per day. Unless a number is tied to a citation, it is a stated design assumption, target, or budget.

The four architectural planes

1. Ingest and transcode plane: resumable upload, validation, mezzanine persistence, transcode DAG, packaging, thumbnails, captions, fingerprinting.
2. Delivery plane: manifest and segment serving, CDN and edge cache hierarchy, adaptive bitrate control loop, QoE telemetry.
3. Discovery plane: search index, recommendation cascade, subscriptions and notifications fan-out, trending.
4. Trust and monetization plane: copyright reference matching, safety moderation, policy packs, ad eligibility and server-side ad insertion, creator analytics.

A strong interview answer keeps these planes separate: the delivery plane must survive a discovery outage, the transcode plane must absorb a viral upload storm without starving partner SLAs, and the trust plane must be able to restrict or remove a video that is already cached in thousands of edge nodes.