Design YouTube (Video Streaming Service)

Design YouTube (or Netflix, or any video streaming service) is the canonical heavy-media pipeline question. Unlike TinyURL, the hard part is not a clever data structure — it is moving petabytes of video from an uploader's laptop to a billion screens, cheaply and smoothly. In 45 minutes it tests whether you can design an asynchronous processing pipeline, reason about blob storage vs databases, explain how streaming actually works (most candidates cannot), and show cost awareness — because at this scale, bandwidth is the business.

The question splits cleanly into two halves: the upload/transcode path (write-heavy, async, throughput-oriented) and the watch path (read-heavy, latency-oriented, CDN-dominated). Structuring your answer around those two paths is itself a senior signal.

Functional requirements

• Users can upload videos (large files — assume up to tens of GB).
• Users can watch videos — this is the product; smooth playback is the requirement, not just "serve the file".
• Users can see view counts on videos.
• (Clarify) Search — call it out, then de-scope it. It is its own interview (an inverted index / Elasticsearch discussion).
• (Clarify) Comments, likes, subscriptions, recommendations — explicitly de-scope. Interviewers want the video pipeline, not a social network.

Non-functional requirements

• High availability on the watch path — playback failures are the product failing.
• Low startup latency — video should begin playing in well under a second of pressing play.
• Smooth playback on flaky networks — a viewer on a train should get lower quality, not a frozen spinner. This one requirement drives the entire adaptive bitrate design.
• Durability of uploads — a creator's 20 GB upload must never be lost mid-way or after ingest.
• Uploads can take minutes to become watchable — processing is async, and that is acceptable. Say this explicitly; it buys you an enormous amount of design freedom.

Use YouTube's public-ish numbers:

• Uploads: ~500 hours of video uploaded per minute → 720,000 hours/day ≈ 43M minutes of source video per day.
• Storage (source): one minute of 1080p source at ~5 Mbps ≈ ~40–50 MB. So ingest is roughly 43M min × 50 MB ≈ ~2 PB of raw video per day.
• Storage (transcoded): each video is stored in ~5–6 renditions (240p → 4K). Lower renditions are much smaller, so the full ladder roughly doubles source storage → ~4–5 PB/day written, forever. This is why cold/archival tiers for old, unwatched videos matter.
• Watch: ~1B hours watched per day = 60B minutes. At an average delivered bitrate of ~1.5 Mbps (mostly mobile/720p) ≈ ~11 MB/min → ~600+ PB/day of egress.

That last number is the punchline: egress is 100×+ the daily storage growth. Even at heavily negotiated pricing of ~$0.01/GB, 600 PB/day is millions of dollars per day in bandwidth. Storage is a rounding error next to delivery. Every architectural choice on the watch path — CDN, compression efficiency, per-title encoding — is really a bandwidth-cost decision.

The key API insight: video bytes never flow through your app servers. The app server hands out pre-signed URLs and the client uploads directly to blob storage, in chunks, so a dropped connection resumes instead of restarting a 20 GB transfer.

Metadata is tiny relative to the video bytes — even billions of videos are a few TB of rows. A relational database (sharded by video_id at extreme scale) is fine; the interesting scaling problems live elsewhere. The status column matters more than it looks: it is what powers the "processing…" state in the UI and the callback when the video goes live.

Why transcode at all? Three reasons, and you should say all three:

1. Devices and codecs — a phone, a smart TV, and an old browser support different codecs (H.264 everywhere, VP9/AV1 where possible for ~30–50% bitrate savings).
2. Resolutions — a viewer on 3G cannot use a 4K stream; you need a ladder of renditions (240p, 360p, 480p, 720p, 1080p, 4K) so the client can pick.
3. Segments — the video is split into small chunks (~2–6 seconds each) so playback can start after downloading one segment and quality can switch at any segment boundary.

Pipeline shape: upload completion drops a message onto a queue. A pool of workers picks it up and executes a DAG of tasks: split the source into segments → transcode each segment into every (resolution × codec) pair in parallel → generate thumbnails → run content/copyright checks → assemble manifests → mark the video READY. The DAG matters because steps have dependencies (manifests need all segments done) but the expensive middle is embarrassingly parallel.

Segmented parallelism is the right answer at YouTube scale, and it composes beautifully with the queue: each segment-transcode task is an idempotent message, workers are stateless and preemptible (spot instances — transcoding is the classic spot workload), and a dead worker just means one small task gets redelivered. A DAG scheduler (or a simple state machine over the encodings table) tracks completion and triggers manifest assembly when the last segment lands.

This is where most candidates hand-wave, and where you can pull ahead by explaining how streaming actually works: it is just HTTP file downloads, orchestrated by the client.

The two dominant protocols are HLS (Apple, .m3u8 manifests) and DASH (MPEG standard, .mpd) — same idea, different container formats:

1. The player fetches a master manifest: a small text file listing the available renditions (1080p @ 5 Mbps, 720p @ 2.5 Mbps, …) and where their segment lists live.
2. Each rendition has a media playlist enumerating its segments: seg_0001.ts, seg_0002.ts, … each ~2–6 seconds of video.
3. The player downloads segments sequentially over plain HTTP and feeds them to the decoder.

Adaptive bitrate (ABR) is the client-side loop on top: the player continuously measures download throughput and buffer level. Buffer growing and throughput high → step up a rendition at the next segment boundary. Buffer draining → step down immediately, because a rebuffer (frozen spinner) is the worst possible outcome. All the intelligence lives in the client; the server is a dumb file server — which is precisely what makes this design scale.

Segments are static, immutable files — the perfect CDN workload. Viewers fetch manifests and segments from an edge server near them; on a miss, the edge pulls from an origin shield (a regional cache layer), which pulls from blob storage. The shield matters: without it, a cache-cold viral video makes thousands of edges hammer the origin simultaneously; with it, the origin sees roughly one fetch per segment per region.

Caching behavior follows viewing behavior, which is brutally skewed: a small fraction of videos generate almost all watch time, while the long tail — billions of videos with a handful of views each — is watched so rarely that caching it is pure waste. That skew drives the central CDN decision:

Two refinements worth mentioning unprompted: popularity-aware placement (hot segments replicated to every edge, warm content only at regional shields, cold long-tail served straight from origin) and pre-warming — when a 100M-subscriber channel publishes, push the first minute of segments to edges before the notification blast goes out, because you know the thundering herd is coming.

A naive UPDATE videos SET views = views + 1 melts on a viral video: millions of writes per minute contending on a single hot row. The fix is to stop counting synchronously:

• Players emit view events to a log/queue (Kafka-style). Nothing on the watch path writes to the database.
• Aggregation workers consume the stream, sum counts per video over a window (say, 10–30 seconds), and flush one batched update per video per window — turning a million increments into a handful.
• Displayed counts are eventually consistent by seconds, which nobody notices or cares about on a view counter.

If asked about exactness: exact counting matters for monetization (creators are paid per view), so the event log is the durable source of truth and batch jobs reconcile precise counts; the real-time displayed number can tolerate approximation. Mentioning approximate structures (like HyperLogLog for unique viewers) is a nice flourish — but know that HLL answers "how many distinct users", not "how many views".

1. Streaming the raw file — no transcoding, no segments, no ABR. This is the single most common failure; it reveals the candidate does not know how video delivery works.
2. Synchronous upload processing — holding the client connection while transcoding runs. Upload must be async with a status machine and callbacks.
3. Putting video bytes in the database — video lives in blob storage; the database holds metadata and pointers. Full stop.
4. Ignoring the CDN or treating it as an afterthought — at 600 PB/day of egress, the CDN is the watch path, not a bolt-on.
5. No resumable uploads — restarting a 20 GB upload from zero on a dropped connection is a design bug, not a corner case.
6. Never mentioning cost — this is the rare question where the dominant constraint is a bill. Candidates who never say the word "egress" leave the strongest signal on the table.