Design YouTube: Video at Planetary Scale

The Numbers That Define YouTube

YouTube Scale (2024):

  Metric                    Value
  ──────────────────────    ────────────────────────
  Video uploaded            500 hours every minute
  Videos watched            1 billion hours/day
  Monthly active users      2.7 billion
  Total videos              800+ million
  Storage                   ~1 exabyte (estimated)

  Upload math:
  500 hours/min * 60 min * 24 hr = 720,000 hours/day
  1 hour raw 4K video = ~50 GB
  720K hours * 50 GB = 36 PB of RAW uploads/day
  After transcoding to multiple formats: ~200 PB/day total

Upload and Transcoding Pipeline

Video Upload Pipeline:

  [Creator's Device]
       |
  1. Resumable upload to GCS
     (supports network interruptions)
     Chunk size: 8-64 MB
       |
  [Google Cloud Storage - raw video]
       |
  2. Transcoding job queued
       |
  [Transcoding Cluster]  (massively parallel)
       |
  Split video into 10-second segments
  For EACH segment, encode:
       |
  Resolutions:  240p, 360p, 480p, 720p, 1080p, 1440p, 4K
  Codecs:       H.264 (universal)
                VP9 (50% smaller, Android/Chrome)
                AV1 (30% smaller than VP9, newest devices)
       |
  7 resolutions * 3 codecs = 21 versions per segment
  1 hour video / 10s segments = 360 segments
  360 * 21 = 7,560 encoded files per hour of video
       |
  3. Store all versions in GCS
  4. Register in metadata DB (Bigtable/Spanner)
  5. Distribute to YouTube CDN edge nodes

Adaptive Bitrate Streaming

DASH/HLS Adaptive Streaming:

  [Video Player]
       |
  Request manifest file (list of available qualities)
       |
  Start playing at medium quality (480p)
       |
  Monitor download speed continuously:
       |
  Download speed > 5 Mbps?  -> Switch to 1080p
  Download speed drops to 2 Mbps?  -> Switch to 480p
  Download speed drops to 500 Kbps? -> Switch to 240p
       |
  Quality switches happen BETWEEN segments
  (every 10 seconds at most)
  User sees smooth playback, not buffering

  This is why quality changes during a YouTube video
  when your WiFi signal fluctuates.

View Counting at Scale

View Count Architecture:

  Gangnam Style: 5 billion views
  Updating a counter in PostgreSQL 5 billion times?
  That is a write lock nightmare.

  Solution: Eventually consistent counters

  [View Event] -> [Kafka] -> [Counter Service]
                              |
                         In-memory increment
                         (per-video counter in Redis)
                              |
                         Flush to Bigtable every 30 seconds
                         (batch write, not per-view)

  Displayed count might be 30 seconds stale.
  Nobody cares if view count shows 4,999,970 vs 5,000,000.

  Anti-fraud: deduplicate by IP + fingerprint
  Same user refreshing 100 times = 1 view

Interview Tip

When designing YouTube, cover: (1) Resumable upload to object storage (handle unreliable connections), (2) Async transcoding to multiple resolutions and codecs (parallel per-segment processing), (3) CDN-delivered adaptive bitrate streaming with DASH/HLS, (4) Eventually consistent view counters via Redis + batch flush. The key trade-off: transcoding 21 versions per segment is expensive but makes streaming efficient for every device and network speed.

Key Takeaway

YouTube's architecture: raw upload to GCS, async transcoding to multiple formats/qualities, CDN delivery with adaptive bitrate. Metadata in Spanner, view counts as eventually consistent Redis counters. The video processing pipeline handles petabytes of new content per day using massively parallel transcoding clusters.

<

/blockquote>