Design YouTube

01The design, in the six-step framework

1. Requirements

Functional

• Upload a video of any size; it becomes watchable within minutes.
• Play on any device and network, choosing quality automatically, with seek.
• Metadata: title, description, channel, view count, likes.
• Out of scope: recommendations (see that design), comments, live streaming, monetisation.

Non-functional

• 2 billion monthly users; 1 billion hours watched a day; 500 hours of video uploaded every minute.
• Playback start in under 1 s, p95; no rebuffering on a stable connection.
• Uploads are never lost after the client is told the upload is complete; processing may be retried.
• View counts may lag by seconds and be approximate on the page; exact for creators' reports by the next day.
• Availability of playback 99.99 percent; the upload path may degrade first.

2. Core entities

• Video: video_id, channel_id, title, description, duration, state (uploading, processing, ready, blocked), published_at.
• Upload session: session_id, video_id, chunk list with received flags, total size.
• Rendition: video_id, resolution, codec, bitrate, manifest and segment object keys.
• View event: video_id, viewer, watch time, timestamp (streamed, not stored per row forever).
• Channel: channel_id, owner, subscriber count.

3. API

• POST /videos with metadata; returns video_id and an upload session. Called by the creator's client.
• PUT /uploads/{session}/chunks/{n}: resumable chunk upload; POST /uploads/{session}/complete when all chunks are in.
• GET /videos/{id}: metadata plus the manifest URL for the player.
• GET https://cdn/…/{video}/{rendition}/manifest.m3u8 and segment files: served by the CDN, not the API.
• POST /videos/{id}/views: a heartbeat with watch position every 30 s. Called by the player.

4. High-level design

From upload to first play:

1. The creator's app creates the video record and uploads the file in 8 MB chunks to the API, which streams each chunk to object storage; a dropped connection resumes at the first missing chunk.
2. On complete, the API marks the video processing and enqueues a job; the client is told the upload is safe.
3. The pipeline splits the source into 4-second segments (keyframe aligned), fans the segments out to a pool of encoders that produce each rendition in parallel, and a packager writes the segments and the HLS and DASH manifests to encoded storage.
4. As soon as the lowest renditions exist the video is marked ready with those; higher renditions are added to the manifest as they finish, which is why a fresh upload plays at lower quality first.
5. A viewer opens the page; the API returns metadata and the manifest URL; the player fetches the manifest and segments from the nearest CDN edge, which pulls from origin on a miss.
6. Every 30 s the player sends a watch heartbeat; the view counter aggregates them in a stream and the page shows a count that is seconds old.

5. Deep dives

How does a 10 GB upload survive a flaky connection, and when is it safe?

A single HTTP PUT of 10 GB fails at the first network hiccup and starts over. Chunked, resumable upload keeps a session record of which chunks have landed; the client asks for the missing set and sends only those, and each chunk write is idempotent on (session, chunk number). The upload is safe when the complete call returns, which the API sends only after all chunks are in object storage, replicated across zones. Processing can fail and be retried any number of times from that raw object; it never asks the client again.

How do we transcode 720,000 hours a day fast enough that a video is watchable in minutes?

Segment-level parallelism is the choice; the work is embarrassingly parallel once the split is keyframe aligned, and workers are stateless, so the fleet scales with the queue depth. Priority goes to the lowest renditions so the video becomes playable early.

Why can 125 Tbps of playback not touch origin, and how does the CDN keep up?

Origin object storage could not serve 125 Tbps, and the bytes would cross the backbone to every viewer. Popular videos follow a steep curve: a few percent of videos are most of the watch time. Edge caches hold the segments of those videos, and the cache key is the segment, not the video, so the edge only stores what is watched. A cache hit rate above 95 percent means origin sees a few terabits per second, which a replicated object store can serve. For the long tail, a second tier of regional caches sits between edge and origin. Segments are immutable, so there is no invalidation problem; a re-encode produces new object keys and a new manifest.

How are view counts both fast and correct?

Writing a row per heartbeat is 1 B hours a day × 120 heartbeats an hour = 120 billion rows a day for a number nobody needs exactly in real time. Heartbeats go into a stream; a windowed aggregation increments an approximate counter per video every few seconds for the page, and a nightly batch over the raw stream, with dedup by viewer and session and filtering of bot traffic, produces the exact numbers creators are paid on. The page is allowed to lag; the ledger is not.

What about a creator deleting or a copyright block while people are watching?

Metadata state is checked by the API on every page load, so a blocked video stops starting within seconds. Segments already cached on edges keep serving existing sessions for their manifest's lifetime, which is bounded by a short manifest TTL; after that the player's next manifest fetch gets a 404 and stops. Permanent deletion of objects is a background job because there are thousands of segments per video.

6. What a strong answer sounds like

• Split the system into three independently scaling paths, upload, processing, playback, and say which one each requirement stresses.
• Quote the numbers: 720 TB a day raw, 2 PB a day encoded, 125 Tbps playback, and that the CDN serves almost all of it.
• Explain segment-level parallel transcoding and why the lowest rendition is produced first.
• Expect follow-ups on adaptive bitrate selection, on storage cost for the long tail (lower renditions only, cold tiers), and on copyright fingerprinting at upload.
• A common mistake is to serve video bytes through the API servers, which turns a bandwidth problem into a CPU problem it cannot solve.

02Where this question was reported

• IGotAnOffer · TPM list: 'Design YouTube'; SWE list: 'How would you distribute YouTube servers?'; page's own example of a Google 45-min prompt is 'Design YouTube'
• Exponent · 'Design a video distribution service' and 'a Google-scale product such as Maps or YouTube' from Exponent's question database (redirects to aced.io)
• interviewkickstart.com · Q1, described as commonly asked; requirements incl. petabyte storage, CDN
• interviewkickstart.com · 'A Video Streaming Service' in the frequently-asked list; also 'your version of Netflix'
• interviewkickstart.com · 'Describe the design of YouTube's Video Streaming Service' (practice question)
• DesignGurus · Tied to YouTube as a Google-owned product
• DesignGurus · Called 'a Google favorite, since YouTube is their product'
• DesignGurus · Listed under common Google questions
• DesignGurus · 'Video Streaming Platform Like YouTube or Netflix'
• Educative · One of 10 'commonly asked' with detailed concerns (transcoding, recs, network drops)
• System Design Handbook · Top-10 list; upload pipeline, CDN, adaptive bitrate
• System Design Handbook · Common Google question