Skip to content
All case studies

YouTube (video streaming)

Accept uploads, transcode them into an adaptive bitrate ladder and stream segments to millions of concurrent viewers. Bandwidth, not requests, is the constraint: the CDN carries the bytes, and transcoding is a large batch pipeline.

Open reference designInteractive lessonPractice an interview
ClientsDNS steeringCDN edge + …Load balanc…Origin 1Origin 2Segment sto…Video metad…Transcode j…Transcoders
Arrows show permitted calls. Open the canvas to inspect route programs.
Component labels and connections
  • Clients (client) · calls: DNS steering
  • DNS steering (dns) · calls: CDN edge + origin shield, Load balancer
  • CDN edge + origin shield (cdn) · calls: Load balancer
  • Load balancer (loadBalancer) · calls: Origin 1, Origin 2
  • Origin 1 (service) · calls: Segment store, Video metadata, Transcode jobs
  • Origin 2 (service) · calls: Segment store, Video metadata, Transcode jobs
  • Segment store (objectStore) · calls: none
  • Video metadata (database) · calls: none
  • Transcode jobs (queue) · calls: none
  • Transcoders (worker) · calls: Segment store

Requirements

Functional

Non-functional

Worked estimates

  • Upload volume

    ≈ 30,000 hours of video per hour of wall clock

    500 hours of video uploaded per minute (YouTube's public figure)

  • Raw ingest

    ≈ 30 TB/hour of originals ≈ 0.7 PB/day

    500 h/min × 60 × ~1 GB/hour (1080p upload)

  • Stored renditions

    ≈ 1 PB/day added before replication or erasure coding

    ~6 renditions totalling ~1.5× the upload size

  • Transcode compute

    tens of thousands of transcoders busy continuously — parallelised per 4 s chunk

    30,000 video-hours/hour × ~1 transcoder-hour per video-hour per rendition ladder

  • Concurrent viewers

    ≈ 42M concurrent streams on average

    1B hours watched/day ÷ 24 h

  • Egress

    ≈ 100 Tbit/s — served from ISP-embedded caches, not data centres

    42M streams × ~2.5 Mbit/s average bitrate

API

POST /upload → PUT /upload/{videoId}/chunk/{n}

Request: resumable chunked upload

Response: 201 per chunk; processing status via GET /videos/{id}

GET /v/{id}/master.m3u8

Request: —

Response: manifest listing renditions and segment URLs

GET /v/{id}/{rendition}/{n}.m4s

Request: byte ranges optional

Response: 200 segment (~4 s of media)

Immutable, so cached at the edge for a long time.

Data model

videos: metadata and processing status, keyed by video ID; view counts are aggregated asynchronously, not updated per view.

segments: immutable objects keyed by (video, rendition, index); the manifest lists them.

Originals are kept (for re-encoding with better codecs later) in colder, cheaper storage.

High-level design

Trace permitted calls in the architecture above, then open the reference canvas to inspect routing.

Deep dives

Adaptive bitrate streaming

Each video is encoded into a ladder (e.g. 240p to 4K at increasing bitrates) and cut into segments of a few seconds aligned at keyframes. A manifest (HLS .m3u8, DASH .mpd) lists them. The player measures throughput and buffer level and picks the next segment's rendition, so it can step down instead of rebuffering. Segments are plain HTTP objects, which is what makes CDNs effective.

The transcoding pipeline

Split the upload into chunks at keyframes, transcode chunks in parallel across many workers, then stitch and publish the manifest. A job DAG (split → encode per rendition → package → thumbnail → publish) with retries per task and idempotent outputs (deterministic object keys) tolerates worker loss. Prioritise short videos and popular creators; batch the long tail.

Delivering 100 Tbit/s

Data-centre egress cannot reach most viewers cheaply. Large platforms place cache appliances inside ISP networks (Google Global Cache, Netflix Open Connect) and steer clients by DNS or by the manifest to a nearby cache that has the content. Popular content is pre-positioned off-peak; the long tail is fetched through regional shields on demand.

Failure scenarios

A video goes viral

Scenario and expected result

One video's segments take 40% of all requests — a new music video premiere.

Expected: The viral segments are cached at the edge after the first fetch; the origin barely notices them. The rest of this scenario's traffic is spread uniformly over the catalogue, so the edge hit rate falls overall and the origin uplink carries more long-tail misses.

Open this scenario

The CDN edge fails and traffic falls back to the origin

Scenario and expected result

The edge dies at t = 1.5 s. After the DNS TTL (300 ms, scaled down) clients go straight to the origin, whose uplink is 2.5 Gbit/s.

Expected: First requests time out until DNS fails over, then the origin uplink saturates: 2,000 segments/s × 256 KB is about 4 Gbit/s against 2.5 Gbit/s of capacity. The link becomes a queue that grows by ~200 MB every second; within a second of failover segment latency is up from milliseconds to over half a second and climbing, and a longer outage ends in timeouts and rebuffering. For video the CDN is not an optimisation: the origin cannot carry the bytes.

Open this scenario

Uploads triple

Scenario and expected result

From t = 1.2 s to 2.2 s all traffic triples, including uploads.

Expected: Chunk uploads are acknowledged as soon as they are stored; transcoding work queues up and videos take longer to become playable. Viewing is unaffected — the CDN is serving it. The transcode queue depth is the capacity signal.

Open this scenario

Alternative designs

Reference

  • Inspect the architecture above and run the same scenario.

No origin shield

  • Without a shield, each edge that misses a segment fetches it from the origin independently, so a newly popular video causes as many origin fetches as there are edges, plus concurrent misses within each. The simulated cell has a single edge, so it cannot show this; the shield's value grows with the number of edge locations.

Reference

  • Inspect the architecture above and run the same scenario.

Progressive download of one file

  • Simplest to serve, but one bitrate for everyone: rebuffering on slow networks, wasted bandwidth on fast ones, and seeking needs byte ranges into a huge file. Segmented adaptive streaming (HLS, DASH) lets the player switch bitrate every few seconds.

Reference

  • Inspect the architecture above and run the same scenario.

Per-title or per-shot encoding

  • A fixed bitrate ladder wastes bits on simple content and starves complex content. Netflix's per-title encoding chooses the ladder per video from its complexity; it costs more compute up front and saves bandwidth on every view, which wins for content watched many times.

Clarifying questions

Common mistakes

Self-assessment rubric

requirements / levels 1-4
  1. 1/4 Upload and watch.
  2. 2/4 Multiple resolutions.
  3. 3/4 Start-up time, rebuffering, durability and scale.
  4. 4/4 Separates upload, processing and playback latency targets.
estimates / levels 1-4
  1. 1/4 None.
  2. 2/4 Upload volume.
  3. 3/4 Storage growth and egress bandwidth.
  4. 4/4 Transcode compute and concurrent streams from watch time.
api / levels 1-4
  1. 1/4 Upload/watch.
  2. 2/4 Chunked upload.
  3. 3/4 Manifests and segments.
  4. 4/4 Resumable uploads and immutable segment URLs.
data model / levels 1-4
  1. 1/4 Videos table.
  2. 2/4 Metadata + blobs.
  3. 3/4 Segments per rendition with manifests.
  4. 4/4 Original retention and async view counting.
high level / levels 1-4
  1. 1/4 Server streams files.
  2. 2/4 CDN + object store.
  3. 3/4 Async transcoding pipeline.
  4. 4/4 Origin shield, ISP caches and steering.
deep dive / levels 1-4
  1. 1/4 None.
  2. 2/4 Mentions bitrates.
  3. 3/4 ABR and the transcoding DAG.
  4. 4/4 Per-title encoding, pre-positioning and failure behaviour.
wrap-up / levels 1-4
  1. 1/4 Stops.
  2. 2/4 Metrics.
  3. 3/4 Rebuffer rate and processing lag.
  4. 4/4 Cost model of egress vs compute and capacity plans for premieres.