Design Youtube
YouTube Design
Difficulty: Hard · Topics: Distributed Systems, Media Streaming, Video Transcoding, CDN Architecture, Cloud Storage · Company Tags: (as originally associated) · Hints: (as originally associated)
YouTube is a video-sharing service where creators upload recorded files, and viewers consume them on demand from many different devices and network connections. From a systems-design viewpoint, the product weaves together two distinct challenges: reliably ingesting very large user uploads without burdening the application tier, and then delivering that same content back to a massive audience as low-latency, segmented streams under extreme read skew.
Functional requirements
- Users must be able to initiate and resume large video uploads without routing raw video bytes through application servers.
- The system must durably record the committed source object and, behind the scenes, package it into multiple streamable renditions plus corresponding manifest files.
- Users must be able to watch a ready video through adaptive-bitrate playback that fetches manifests and short media segments over HTTP.
- Clients must be able to retrieve upload/playback status and core video metadata using either an
upload_idor avideo_id. - The server must enforce an explicit lifecycle: a video only becomes watchable after packaging finishes and metadata declares it "ready."
Non-functional requirements
- Emphasize high availability for playback and metadata reads while keeping the "publish" boundary for a finished video explicit and durable.
- Aim for roughly
300 msto create an upload session and200 msp95 for playback bootstrap (manifest lookup or the first critical request). - Support about
1Muploads per day,100Mvideo watches per day, videos reaching tens of GB, and severe hot-video read skew concentrated on a small share of titles. - No acknowledged raw upload or published packaged asset should be lost after commit.
- Authenticate uploaders, use signed upload/playback access where needed, and keep object storage private behind controlled origin access.
- Keep bulk bytes off application servers, lean on CDN offloading for reads, and separate hot packaged assets from colder raw-upload retention.
Back-of-the-envelope estimation
| Quantity | Assumed value | Purpose |
|---|---|---|
| Uploads per day | ~ 1M | upload-session churn, multipart cleanup, packaging queue load |
| Watches per day | ~ 100M | CDN and origin read skew, metadata lookup rate |
| Mean packaged size per minute of video (all renditions) | ~ 10–50 MB | storage and egress order-of-magnitude |
| Typical segment duration | 2–10 s | segment count per watch, cache-key churn |
| Playback bootstrap budget | ~ 200 ms p95 | metadata store sizing, caching of small responses |
| Hot video multiplier | to of median traffic | CDN fill, origin shielding, regional promotion |
These numbers clarify why the watch path cannot be "read one enormous file from a database," why metadata lookups must stay cheap and keyed, and why segments and manifests serve as the unit of caching and retry. The 200 ms bootstrap budget drives the metadata path toward one small keyed read, while the hot-video multiplier makes first-segment cache fill and origin shielding a first-class design decision rather than an afterthought.
High‑level YouTube system design showing upload ingestion and adaptive‑bitrate playback delivery.
Out of scope (below the line)
- Search, recommendations, channels, comments, likes, and subscriptions.
- Live streaming and live chat.
- Detailed content moderation and abuse-review workflows beyond basic auth boundaries.
- Exact view counts, monetization, and full analytics pipelines.