YouTube System Design: The Challenge

YouTube says that, on average, over 20 million videos are uploaded every day. Each video must be processed into many formats, stored safely, and streamed smoothly to billions of devices, from a 4K TV on fibre to a budget phone on a patchy mobile connection.

Designing a video platform like YouTube is a favourite system design interview question because it combines heavy background processing, massive storage, and global delivery. Here's how the pieces fit.

🎯 Quick Answer (30-Second Read)

  • Upload: the raw file goes to object storage; metadata goes to a database.
  • Transcoding: a background pipeline converts each video into many resolutions and codecs, split into small segments.
  • Streaming: players use adaptive bitrate streaming (e.g. DASH or HLS), switching quality every few seconds based on network speed.
  • Delivery: popular videos are served from CDN and edge caches, including caches inside internet providers.
  • Metadata at scale: YouTube built Vitess to shard MySQL; it's now an open-source CNCF project.

High-Level Architecture

flowchart TB CR["🎥 Creator"] -->|"upload"| UP["Upload service
(resumable)"] UP --> RAW[("Raw video storage")] UP --> META[("Metadata DB
title, owner, status")] UP --> Q[["Processing queue"]] Q --> TX["Transcoding workers
144p … 4K, multiple codecs"] TX --> SEG[("Segment storage
2–10 s chunks")] TX --> THUMB["Thumbnails, captions,
content checks"] SEG --> CDN["CDN / edge caches
(incl. inside ISPs)"] V["📱 Viewer"] --> API["Watch API"] API --> META API -->|"manifest"| V V -->|"segments"| CDN V -->|"view & watch events"| EV[["Event stream"]] --> AN["Analytics, counts,
recommendations"]

Step 1: Uploading

Large files over unreliable networks need resumable uploads: the file is sent in chunks, so a dropped connection resumes instead of restarting. Once the upload completes, the video's status is "processing" and a job goes onto a queue.

Step 2: Transcoding

The uploaded file might be a huge 4K file in one codec. Viewers need many versions:

Output Why
Multiple resolutions (144p to 4K and above) Match screen size and network speed
Multiple codecs (H.264, VP9, AV1) Newer codecs save bandwidth; older devices need H.264
Short segments (a few seconds each) Let the player switch quality mid-video
Thumbnails, captions Discovery and accessibility

Transcoding is CPU-heavy, so the video is split into chunks processed in parallel by many workers, then reassembled. That's how a long video can be ready in minutes instead of hours. (YouTube has also built custom video-transcoding chips to make this cheaper.)

Step 3: Adaptive Bitrate Streaming

sequenceDiagram participant P as Player participant A as Watch API participant C as CDN edge P->>A: Play video abc123 A-->>P: Manifest (list of qualities + segment URLs) P->>C: Segment 1 @ 720p C-->>P: ✓ (network fast) P->>C: Segment 2 @ 1080p Note over P: Network slows down P->>C: Segment 3 @ 480p C-->>P: ✓ no buffering

The player measures how fast segments arrive and picks the best quality it can sustain. That's why quality sometimes drops briefly instead of the video freezing.

Key takeaway: splitting videos into small segments at many quality levels is what makes smooth streaming possible on any network. The player, not the server, decides which quality to fetch next.

Step 4: Delivery With CDNs

Video bytes are by far the biggest load. Serving them from central data centres would be slow and expensive. Instead:

  • Popular videos are cached on edge servers close to viewers. Google runs caches inside many internet providers' networks through Google Global Cache.
  • Long-tail videos (rarely watched) are fetched from deeper storage on demand.
  • A tiny share of videos accounts for a large share of views, so caching the popular ones covers most traffic.

Step 5: Metadata and Vitess

Video titles, channels, comments and subscriptions live in databases. As YouTube grew, a single MySQL database couldn't keep up, so YouTube built Vitess, a system that shards MySQL across many servers while applications still talk to it like one database. Vitess was later open-sourced and is now a CNCF graduated project used by other large companies.

Step 6: Counting Views

Updating one database row per view for a viral video would melt it. Instead, view and watch-time events are written to a stream, aggregated in batches, and counts are updated periodically. Views also go through checks to filter out spam and bots, which is why counts can lag or be adjusted.

Interview Checklist

  • Resumable uploads to object storage
  • Queue-driven, parallel transcoding into segments
  • Adaptive bitrate streaming with a manifest
  • CDN and edge caching for popular content
  • Sharded metadata database
  • Asynchronous, aggregated view counting
  • Recommendation pipeline fed by watch events (How the YouTube Algorithm Works)

Frequently Asked Questions

How does YouTube stream video so smoothly?

YouTube transcodes each video into many quality levels split into short segments. The player downloads segments one at a time and picks the highest quality the network can handle, switching up or down as conditions change. Popular segments are served from nearby CDN caches.

What database does YouTube use?

YouTube built Vitess to scale MySQL by sharding it across many servers. Vitess is now an open-source CNCF graduated project. Video files themselves are stored in large-scale object storage rather than databases.

How would you design YouTube in a system design interview?

Cover resumable uploads, a queue-based transcoding pipeline producing segmented multi-resolution outputs, adaptive bitrate streaming, CDN delivery, a sharded metadata store, and asynchronous view counting. Then discuss trade-offs like storage cost for many formats and caching popular versus long-tail videos.

Conclusion

YouTube works by doing the heavy lifting before anyone presses play: uploads are processed in parallel into many quality levels and short segments, and popular content is cached close to viewers. Adaptive bitrate players, sharded metadata with Vitess, and stream-based view counting complete the picture.

Sources

Last verified: 2 November 2026.

Related reads: How the YouTube Algorithm Works · Why Netflix Rarely Goes Down · How Hotstar Handles Crores of Live Viewers · Message Queue Explained

I write about system design and how real products are built. Follow on LinkedIn or X, or invite me to speak.