Worked Example 15.4 · 4 of 15

Design YouTube / a video streaming platform

📖 6 min read · 12 sections · May 2026

Asked at: Google Meta Netflix Amazon Prime

The setup

"Design YouTube. Focus on: video upload, processing (multiple resolutions), and global streaming to viewers. Scale: 500 hours of video uploaded per minute; 1 billion hours watched per day."

The interviewer is testing whether you understand that video at internet scale is fundamentally a CDN problem, not a database problem. 95%+ of bytes are served from edge caches; only 5% touch origin. The architecture you design must reflect this.

Clarifying questions

Question	Story answer
Live streaming or just uploaded videos?	Pre-uploaded only.
What resolutions do we support?	144p through 4K. Discuss the resolution ladder.
Recommendations, comments, search?	Out of scope — upload + storage + playback only.
Geographic distribution?	Global, must be fast everywhere.
Are videos public or do we have access control?	Public for this design; mention auth-gated streams briefly.

Capacity estimation

Upload:
  500 hours/min ÷ 60 = ~8.3 hours/sec
  Avg 1080p H.264: ~1 GB/hour → ~8.3 GB/sec of upload bandwidth
  Daily: 500 × 60 × 24 = 720,000 hours/day
  Storage: 720,000 × 1 GB = ~720 TB/day of raw video
  
With multi-resolution variants (5+ resolutions × different bitrates):
  ~5× storage = 3.6 PB/day
  Per year: ~1.3 exabytes

Streaming:
  1B hours/day ÷ 86400 sec = ~12M concurrent viewers average
  Peak (3×): ~40M concurrent at events; sustained ~25M typical peak
  Avg bitrate: 2 Mbps (most viewers watch 720p or lower)
  Total bandwidth: 25M × 2 Mbps = 50 Tbps sustained, peaks higher

For context: AWS's total egress capacity is in the same order of magnitude

Storage cost: 1.3 EB/year × $0.02/GB-month for cold storage = ~$300M/year just for storage. Hot storage (recent + popular videos) costs more per GB but is a smaller fraction. The cost of running YouTube is dominated by bandwidth (CDN egress) and storage, not by compute.

The architecture in three layers

UPLOAD PATH:
Creator ──(multipart upload)──► CDN edge upload endpoints
                                       ↓
                              S3-class origin storage
                                       ↓
                              S3 event → Kafka topic
                                       ↓
                          ┌─── Encoding worker pool ───┐
                          │ Transcode to:               │
                          │   144p, 240p, 360p, 480p,  │
                          │   720p, 1080p, 1440p, 4K   │
                          │ Slice into HLS/DASH        │
                          │ segments (6-10 sec each)   │
                          └────────────┬───────────────┘
                                       ↓
                              Encoded outputs to S3
                                       ↓
                              CDN warm-up (push to popular POPs)

PLAYBACK PATH:
Viewer ◄── CDN edge POP (cache hit ~95%) ◄── Mid-tier ◄── Origin S3
Manifest (.m3u8 / .mpd): tells player about available bitrates + segment URLs
Player downloads segments adaptively as user watches

Design Decision 1: HLS vs DASH vs MP4

Format	How	Pros	Cons
Single MP4 file	One file at one resolution; player downloads as it plays	Simple	No bitrate adaptation; player stalls if bandwidth drops
HLS (HTTP Live Streaming)	Apple standard. Manifest (.m3u8) lists segments at multiple bitrates; player picks per segment	Wide support; works through any HTTP CDN; adaptive	Apple-specific origins; some platforms add overhead
DASH (MPEG-DASH)	Open standard, similar concept to HLS	Vendor-neutral; flexible	Less Apple device support; fragmentation across players

YouTube uses DASH primarily; mobile platforms use HLS where needed. Both are segment-based protocols enabling adaptive bitrate streaming (ABR). Pick segment-based for this design — single-MP4 is unviable at scale.

Design Decision 2: Encoding pipeline

One uploaded video must be transcoded to many output formats. For a 10-minute 1080p video, encoding to 5 resolutions takes:

~5 minutes on a fast CPU per resolution
~5× faster with GPU (NVENC) but more $$$/min
Total: 25 CPU-minutes per uploaded minute, or 5 GPU-minutes

At 8.3 hours uploaded per second × 25 CPU-minutes per uploaded minute, we need a transcode farm of roughly 8.3 × 60 × 25 = 12,500 CPU-cores running continuously just for encoding (or fewer GPUs). This farm runs on Kafka-consumed jobs from the upload queue.

The multi-stage encoding insight: encode the lowest resolution first (480p), make it available immediately, then encode higher resolutions in the background. Viewer can watch 480p within minutes of upload completion; 1080p takes longer; 4K can take an hour for long videos. This is a UX win — videos appear "ready" quickly.

Design Decision 3: CDN tier architecture

Tier	What	Latency	Storage
Edge POP (Point of Presence)	Hundreds globally; often inside ISP networks ("embedded caches"); hot content cached	10-50ms to viewer	~1 PB per POP — top videos only
Regional mid-tier	Tens of regional aggregation caches	20-100ms to POPs	~10 PB per region — broader catalog
Origin	Centralized S3-class object stores	varies — only cache misses	Full catalog (1.3 EB+)

Cache hit rates: ~95%+ at edge for the top 1% of videos (the popular ones). Long-tail videos miss edge but hit mid-tier; only the very rare deep-cold video hits origin.

Why three tiers? Because each layer's job is different:

Edge POP: as close to viewer as possible; small but very hot cache
Mid-tier: broader catalog; serves edge misses; less latency-sensitive than edge but more than origin
Origin: source of truth; serves the long tail

Bandwidth math: 50 Tbps sustained. If 95% from edge: 47.5 Tbps from POPs (distributed across hundreds; each handles ~50-500 Gbps). 5% to mid-tier: 2.5 Tbps. <0.1% to origin: ~50 Gbps. Origin doesn't need to be massive; edges do.

Cross-examination round 1: viral video

Interviewer: A video goes viral. 10M views in 1 hour. Walk through CDN behavior.

First view in each region misses POP cache. POP fetches from mid-tier. If mid-tier misses, fetches from origin. Both populate caches as data flows back. After 5-10 minutes per region, the viral video is fully cached at all edge POPs that serve viewers for it. 10M views generate maybe a few thousand origin fetches total (one per region per resolution).

Follow-up: But the first 1,000 simultaneous viewers in the same region all miss the edge cache.
A: Cache stampede. Edge POP uses singleflight: only one upstream fetch per missed segment; subsequent concurrent requests wait on it. So 1,000 simultaneous requests for one segment generate 1 mid-tier fetch, not 1,000.

Follow-up: The video is 4K, 100 GB total. CDN can't cache the full video at edge — that's a lot of cache.
A: Edge caches segments individually, not whole videos. A segment is ~10 MB at 4K. Cache 5 minutes' worth of recent segments (about 30 segments). Older segments fall out of cache; if viewer scrubs to early in the video, re-fetched from mid-tier. The cache pattern is: hot segments stay hot.

Cross-examination round 2: pre-warming

Interviewer: When a creator with 100M subscribers uploads a video, we know it's going to be popular. Can we be smart?

Yes. Predictive caching. On upload, identify "high-likely-viral" videos (popular creator, certain channels, time of day, prior view-rate patterns). Push these to all major edge POPs immediately, before users request them. Cost: a few GB of pre-pushed data; benefit: zero cold-cache misses on first wave of views. The reverse signal also matters — videos from new creators with no followers don't need pre-push; they may never be watched.

Cross-examination round 3: adaptive bitrate streaming

Interviewer: Walk through what the video player does as the user's bandwidth fluctuates.

Player downloads the manifest first (lightweight; tells it all available bitrates and segment URLs). Player measures current download speed of the first segment. Based on bandwidth + buffer health, picks the highest bitrate it can sustain. Downloads segments at that bitrate. As bandwidth drops (mobile network flickers), player switches to lower bitrate segments. Algorithm typically targets ~30 sec of buffer; aggressive switching down if buffer is below 10 sec, conservative switching up. The server doesn't need to know — it just serves whichever segment the player requests.

Failure mode analysis

Failure	Mitigation
Edge POP goes down	BGP / DNS routes viewers to next-nearest POP. ~30-60 sec disruption for affected viewers; full recovery within minutes as cache warms at new POP.
Encoding worker fails mid-job	Kafka consumer offset not committed → another worker picks up. Encoding is idempotent (output file is overwritten on re-encode).
Origin S3 outage	Existing cached content unaffected. Cold videos unavailable until origin recovers. Common pattern: alternate origin (multi-region S3) for HA.
Mid-tier saturated	Edge fetches slow; viewer stalls. Auto-scale mid-tier capacity; pre-emptively expand for events known in advance.

Takeaway

YouTube-scale systems are 5-10 separate hard systems glued together: upload infrastructure, encoding farm, segment-based streaming protocol, multi-tier CDN, recommendation engine, analytics. The interview test is whether you can identify the right subsystems and articulate their interactions, not whether you can encode a single complex algorithm.

The deepest single technical insight: video at internet scale is fundamentally a CDN problem. 95% of bytes are served from edges; only 5% touch your origin. Architecture is dominated by where bytes live and how they propagate from origin to edges. Encoding cost is real but bounded; storage cost grows linearly with content; bandwidth cost grows with views and is the largest line item at scale.