AlgoInsight

System Design

Design YouTube

Everyone thinks the hard part is storing the videos. It isn't. The hard parts are the transcoding pipeline that turns one upload into a dozen formats, and the delivery network that streams them to billions without buffering. Here's how to design it.

By Admin2026-06-1816 min readyoutubevideo-streamingsystem-designcase-studyinterviewcdn

"Design YouTube" - or any large video platform: users upload videos, others stream them - is a question I love because candidates almost always focus on the wrong thing. They obsess over the database and how to store metadata, when the genuinely hard problems lie elsewhere: the transcoding pipeline that converts one uploaded video into many formats and resolutions, and the delivery network that streams enormous video files to billions of viewers without buffering. Get the candidate to those two problems and you learn whether they understand how video platforms actually work.

Here's how I'd want this designed, with my interviewer's notes on where it's really won.

Scope it

Narrow to the core. Functionally:

Non-functional requirements that drive the design:

Interview: Early on, I'm watching for two realizations: that the system is extremely read-heavy (watching vastly exceeds uploading), and that videos are large binary files that must be processed and delivered, not just stored. The candidates who frame it this way head toward the real problems. The ones who spend ten minutes designing the metadata schema, as if this were a CRUD app, are about to miss what makes a video platform hard.

The upload and the easy part

When a user uploads a video, the raw file goes into object storage - built for large binary files - not a database. The database stores only metadata: title, uploader, description, and references to the stored video files. This separation (big files in object storage, structured metadata in the database) is the same standard pattern that applies to any media-heavy system, and getting it right quickly lets you move on to the parts that matter.

But the raw uploaded file isn't ready to stream yet. That's where the first hard problem begins.

The first hard problem: the transcoding pipeline

A single uploaded video can't serve everyone. Viewers watch on phones, laptops, and TVs, over fast and slow connections, so the platform needs the video in multiple resolutions and formats (1080p, 720p, 480p, and so on) and in formats suited to streaming. Converting the raw upload into all these versions is transcoding, and the transcoding pipeline is one of the two defining challenges.

Transcoding is slow and compute-heavy - it can't happen during the upload request while the user waits. So it must be asynchronous: the upload is accepted and stored, and then the transcoding work is handed off to a background pipeline. This is a textbook use of a message queue - the upload service drops a "transcode this video" job onto a queue, and a fleet of transcoding workers pulls jobs and processes them, converting the video into all needed versions and storing each in object storage. (See the message queues guide for why moving slow work off the request path onto a queue is the right pattern.)

graph LR
    U[User uploads video] --> UP[Upload Service]
    UP --> OBJ[(Object Storage<br/>raw file)]
    UP --> Q[Transcode job queue]
    Q --> W[Transcoding workers<br/>convert to many formats]
    W --> OBJ2[(Object Storage<br/>transcoded versions)]
    W --> DB[(Metadata: ready to stream)]

This diagram shows YouTube's upload and transcoding pipeline. A user uploads a video to the Upload Service, which stores the raw file in object storage and drops a transcode job onto a queue. A fleet of transcoding workers pulls jobs from the queue, converts each video into many formats and resolutions, stores those versions in object storage, and updates the metadata to mark the video ready to stream. The transcoding is asynchronous, off the upload request path.

The pipeline also benefits from breaking large videos into segments and transcoding them in parallel across many workers, which speeds up processing of long videos - a two-hour upload can be transcoded far faster when split into chunks that dozens of workers handle simultaneously, rather than one worker grinding through the whole file. A candidate who recognizes that transcoding must be asynchronous (queue plus worker fleet), and ideally that it can be parallelized by segmenting the video, is demonstrating real understanding of how upload-heavy media systems work.

Interview: The transcoding pipeline is the first place I find out if a candidate gets it. The weak answer treats the upload as "store the file and you're done." The strong answer recognizes that the raw file must be transcoded into many versions, that this is slow and must happen asynchronously via a queue and a worker fleet, and that you mark the video "ready" only once processing completes. If they add parallelizing by segmenting the video, that's a senior-level signal. This is where over-focusing on the database costs candidates and recognizing the async pipeline wins.

The second hard problem: streaming and delivery

Now the bigger challenge: streaming those videos to billions of viewers worldwide, smoothly. Two pieces matter here.

The CDN is everything. Video is enormous, and serving it from a central origin to viewers worldwide would be slow and would overwhelm the origin. So video content is served from a CDN - a globally distributed network that caches video close to viewers. A viewer in Tokyo streams from a nearby edge server, not a distant data center, which is what makes playback start fast and stream smoothly. For a video platform, the CDN isn't an optimization - it's the core of the delivery architecture. The vast majority of streaming traffic is served from the CDN, never touching the origin. (See the CDN material in the building-blocks guide.)

Adaptive bitrate streaming. To avoid buffering across varying connections, video is delivered using adaptive bitrate streaming: the video is split into small segments available at multiple quality levels, and the player automatically switches quality based on the viewer's current bandwidth - dropping to a lower resolution when the connection slows, raising it when it improves. This is why a video keeps playing (at lower quality) instead of freezing when your connection dips. Recognizing that smooth playback comes from segmented, adaptive, multi-quality delivery - not from serving one big file - shows you understand modern video streaming.

View counts and the read path

Showing view counts at YouTube's scale has a familiar twist. Incrementing a counter in the database on every single view, for billions of views, would be a massive write hot spot. The pragmatic approach is to handle view counts asynchronously - emitting view events to a stream and aggregating them in the background (the batch/stream processing pattern), and accepting that the displayed count can be slightly delayed or approximate. Nobody needs a viral video's count to be exact in real time. A candidate who flags that per-view synchronous counter writes would be a hot spot, and proposes async aggregation, is showing scale awareness. (See the batch vs stream processing guide.)

Deep dive: estimating the scale

Grounding in numbers clarifies the priorities. Say a large platform ingests hundreds of hours of video per minute and serves billions of views per day. The view-to-upload ratio is enormous - videos are watched vastly more than uploaded - confirming the system is overwhelmingly read-heavy and that delivery (the CDN) is where most of the load lives. The storage is staggering too: billions of videos, each transcoded into several versions, means exabytes of storage, which is why object storage (cheap, durable, built for scale) is the only sensible choice for the files. These magnitudes justify every major decision: object storage for the files, an async pipeline for compute-heavy transcoding, and a CDN carrying the overwhelming majority of delivery traffic.

Deep dive: resumable uploads

A practical upload detail interviewers like: video files are large, and uploads over imperfect connections can fail partway. A naive design that makes the user restart a failed upload from scratch is poor. The better approach supports resumable, chunked uploads - the file is uploaded in chunks, and if the connection drops, the upload resumes from the last successful chunk rather than restarting. This also lets the platform begin processing chunks as they arrive. Recognizing that large-file uploads need chunking and resumability - rather than a single all-or-nothing transfer - shows attention to the real-world upload experience.

Deep dive: thumbnails, previews, and preprocessing

Beyond transcoding to multiple resolutions, the processing pipeline does more: generating thumbnails (still frames for the preview image), creating short hover-previews, and extracting metadata. All of this is part of the same asynchronous pipeline - more jobs for the worker fleet, triggered when a video is uploaded. A candidate who recognizes that "processing" a video means more than transcoding - thumbnails, previews, and metadata extraction, all done asynchronously - shows a fuller picture of what the upload pipeline produces. It reinforces the central point: a lot of compute-heavy work happens between upload and "ready to watch," and all of it belongs off the request path in the async pipeline.

Deep dive: popular vs long-tail content

Here's a storage-and-delivery nuance I push senior candidates on. Video popularity is wildly skewed: a tiny fraction of videos get the overwhelming majority of views, while billions are watched rarely. This shapes delivery and storage. The hugely popular videos should be aggressively cached in the CDN (kept hot at the edge everywhere), while the long tail doesn't need to occupy expensive edge cache and can be served from the origin or fetched into cache on demand when someone watches. On the storage side, rarely accessed videos can live on cheaper, colder storage tiers, while popular ones stay on faster storage. A candidate who recognizes the popularity skew and tailors caching and storage tiers accordingly - hot content cached aggressively, cold content on cheaper storage - is operating at a genuinely senior level.

Deep dive: what happens when you press play

Tracing a single view ties the delivery pieces together. When a viewer presses play, the player first fetches the video's metadata and a manifest - a small file listing the available quality levels and the segments that make up the video. The player then requests video segments from the CDN, starting at a quality appropriate for the viewer's bandwidth, and as playback continues it monitors the connection and requests subsequent segments at higher or lower quality (adaptive bitrate). Because the segments come from a nearby CDN edge, playback starts quickly and stays smooth. Notice the origin and metadata database are barely involved in the actual watching - a tiny initial metadata fetch, then it's all CDN-served segments. This is the read-heavy nature made concrete: the watch path is engineered so the vast majority of work is served from the edge, never touching the core systems. A candidate who can trace this flow - manifest, then adaptive segment requests from the CDN - demonstrates they understand how streaming actually works end to end.

What I'd push a senior candidate on

For senior candidates, after the core design, I probe the operational realities. How do you manage CDN cache efficiently given the popularity skew? How do you handle the transcoding pipeline's load when uploads spike (the queue absorbs it, and the worker fleet scales)? How do you keep costs sane at exabyte scale (storage tiering, and not eagerly transcoding rarely-watched videos into every possible format)? These reveal whether a candidate thinks about the economics and operations of a system at this scale, not just its architecture. At YouTube's scale, cost and efficiency are first-class design concerns, and a senior candidate treats them as such.

Putting it together

The full architecture:

Challenge The trap The strong answer
Store the video Put it in the database Object storage for the file
Make it streamable Serve the raw upload Async transcoding pipeline (queue + workers)
Deliver globally, smoothly Serve from origin CDN + adaptive bitrate streaming
View counts at scale Synchronous counter writes Async aggregation (stream processing)

Interview: What gets you hired on "Design YouTube": getting past the metadata quickly, then nailing the two hard problems - the asynchronous transcoding pipeline (queue and workers, producing multiple formats) and the CDN-centric delivery with adaptive bitrate streaming. Add async view-count aggregation and you've covered the scale hot spots. The candidates who struggle are the ones who spend the interview on the database and never reach transcoding or CDN delivery - which is where a video platform's real engineering lives. My single best piece of advice for this question: say "the database is the easy part" out loud early, then spend your time where the difficulty actually is.

The bottom line

Designing YouTube isn't really about storing videos - that's just object storage. The two hard problems are the transcoding pipeline (asynchronously converting each upload into many formats via a queue and a worker fleet, since transcoding is too slow to do inline) and the delivery network (a CDN serving video close to viewers worldwide, with adaptive bitrate streaming for smooth, buffer-free playback). View counts add a familiar scale twist, handled with asynchronous aggregation. The whole system is shaped by being massively read-heavy and media-heavy, and nearly every decision - object storage, async processing, CDN delivery, storage tiering for the popularity skew - flows from those two characteristics.

Get past the database quickly, recognize that transcoding and CDN delivery are where the difficulty lives, and you've understood how video platforms actually work. We work through case studies like this end to end across System Design Fundamentals.

Go deeper

More articles