SDE Path

Video upload, transcode & CDN

Design YouTube

Hard

Ingest 500 hours of video every minute, transcode each upload into a full quality ladder, and stream it to a billion viewers from a CDN edge near each one.

YouTube is a user-generated-video platform: creators upload raw video, the system processes it, and billions of viewers stream it back on every kind of network and screen. What makes it a hard system-design problem is the pipeline that sits between upload and playback.

Three forces define the design:

  • Ingest is write-heavy and bursty — ~500 hours of new video arrive every minute, in every format, over flaky uplinks. Uploads must be resumable and durable.
  • Transcoding is compute-heavy — one raw master must become a whole ladder of resolutions and codecs (240p → 4K, H.264 / VP9 / AV1) so any device on any bandwidth can play it.
  • Delivery is read-heavy and global — billions of views/day at hundreds of Tbps, which is only possible if the bytes are served from a CDN edge near the viewer, not from origin.

The whole design is about turning a messy UGC upload into immutable, cacheable segments and getting them as close to the viewer as possible. This is the canonical "ingest → transcode → CDN" interview.

Start by scoping. The interviewer wants to see you separate the write path (upload → transcode) from the read path (watch/stream) early — that split, and naming transcoding + CDN as the crux, drives every later decision. Trim the surface to the handful of things you'd actually build in 45 minutes; comments, likes, and multi-device sync are ordinary web features that hang off the core pipeline.

Functional

  • Upload a video of any format/size — resumable/chunked so a dropped connection can continue.The raw master is stored durably before any processing begins.
  • Transcode each upload asynchronously into a ladder of resolutions + codecs for adaptive streaming.e.g. 144p…2160p in H.264 (compatibility) plus VP9/AV1 (efficiency), packaged as HLS/DASH.
  • Stream/watch a video with adaptive bitrate — the player picks quality from live bandwidth.Plays on web, mobile, and TV; engagement (views/likes/comments) is tracked per video — view counting is a deep dive.
  • Browse & search videos and view metadata (title, description, thumbnail, channel).

Non-functional

  • Playback start < ~2 s p99 and near-zero rebuffering under normal networks (delivery latency dominates UX).
  • High availability on watch — 99.99%+; the read path survives viral spikes on a single video.
  • Massive scale — ~1B DAU, ~5B views/day; ~500 hours of video ingested per minute.
  • 11-nines durability for masters and renditions — an uploaded video is never lost.
  • Global low-latency delivery — >95% of bytes served from a CDN edge; peak egress in the hundreds of Tbps.
  • Elastic transcoding — a 10-minute video is watchable within minutes of upload, even under upload bursts.

Out of scope

  • Recommendations/ranking ML
  • Ads & monetization
  • DRM & Content-ID copyright matching
  • Live streaming (focus on VOD)
  • Comments & social graph UI

Check yourself· 3 questions

Question 1

Which pair of concerns is the crux of YouTube and shapes the whole system?

Question 2

Why must uploads be resumable rather than a single PUT?

Question 3

Why is adaptive bitrate (ABR) a functional requirement rather than a nice-to-have?