"Design YouTube" sounds easy — creators upload videos, viewers press play. But underneath, a lot is happening: huge files get stored, the video gets re-made into many sizes, and a worldwide delivery network moves it to people fast. The same design works for any video site, like Netflix or Hulu. The senior move here is knowing which pieces to buy (rent from the cloud) instead of build yourself.
The animation on the right follows one video from start to finish: a creator uploads the original file to blob storage → transcoding servers re-make it into many versions (check it → encode 360p / 720p / 1080p + a thumbnail) → those versions go out to the CDN (servers near viewers) → a viewer streams the quality that fits its internet speed from the closest server, then drops to a lower quality when the connection gets weak.
Step 1: Ask questions and estimate the size
For an interview, the whole product is just watching and uploading. Skip comments, likes, playlists, and subscriptions. First, pin down what you are building:
- Upload videos fast, and play them back smoothly
- Let the video quality change to match the user's internet speed (adaptive bitrate)
- Clients: mobile apps, web browser, smart TV
- Users all over the world, encryption required, biggest video size is 1 GB
- Keep infrastructure cost low; the system should rarely go down, handle growth, and be reliable
- Use cloud services that already exist (CDN, blob storage) — do not build them yourself
Back-of-the-envelope estimation
Start with the numbers — they explain every choice you make later. Two numbers drive this whole design: how much storage you need each day (which is why you need blob storage + transcoding) and how much it costs to send video out of the CDN (which is why the cost-saving tricks below exist). Say both out loud before anyone asks.
Assume: 5M daily active users, each watches 5 videos a day, 10% of them upload 1 video a day, and the average video is 300 MB.
Daily storage = 5M users × 10% × 300 MB
= 150 TB / day
CDN egress = 5M users × 5 videos × 0.3 GB × $0.02/GB (CloudFront, US)
= $150,000 / day
Storing 150 TB every day is why we never let raw video files touch the API servers. And $150K a day just to send video out of the CDN is why a whole section below is about not serving everything from the CDN.
Step 2: High-level design
At the top level there are only three pieces. The key trick is keeping all the streaming traffic away from the API servers.
Blob storage
A "Binary Large Object" store. It holds an entire video as one big chunk of data — it does not care what is inside. We use two of them: original storage for the raw upload, and transcoded storage for the re-made versions.
| Component | What it does |
|---|---|
| Client | Computer, phone, or smart TV — uploads and plays videos |
| CDN | Stores videos on servers near viewers and streams playback; the closest server serves you |
| API servers | Everything except streaming: recommendations, signup, video info (metadata), making upload links |
The interviewer cares about two paths through the system: uploading a video and streaming a video.
Upload flow
Two separate things happen at the same time:
- Upload the file. The client asks the API for a pre-signed URL (a special temporary upload link), then writes the original video straight into blob storage — skipping the API servers. Transcoding servers then grab it, re-make it into many versions, and push those out to the CDN. When that finishes, a completion queue tells a handler to update the video info (metadata) database and cache.
- Save the video info. At the same time, the client sends the video's metadata (name, size, resolution, format, who uploaded it). API servers save it into the Metadata DB, which is split across machines (sharded) and has a cache in front.
Streaming flow
Streaming is not the same as downloading. With streaming, the client gets a little bit of video at a time, so playback starts right away instead of waiting for the whole file. Videos stream from the CDN server closest to the viewer, which keeps the delay low.
Streaming protocol
A standard set of rules for moving video data to the player. Examples: MPEG-DASH (Dynamic Adaptive Streaming over HTTP), Apple HLS (HTTP Live Streaming), Microsoft Smooth Streaming, and Adobe HDS. Different protocols work with different video formats and players — pick the one that fits your clients.
Just say "blob storage" and "CDN" and move on — explaining how they work inside is overkill. Even Netflix runs on AWS and Facebook uses Akamai. Picking the right managed service is the good signal; trying to rebuild S3 from scratch in an interview is a bad signal.
Step 3: Deep-dive — video transcoding
Raw video is no good for streaming. An hour of HD at 60 fps can be hundreds of GB, devices only play certain formats, and you want to give fast connections high quality while slow connections still get something that plays. Transcoding means re-encoding the original into many sizes and formats. (Encoding = compressing video into a playable file.)
Every encoded file has two parts:
- Container — the wrapper that holds the video, audio, and metadata together (
.mp4,.mov,.avi). - Codec — the method used to compress and decompress the video: H.264, VP9, HEVC.
The DAG model
DAG pipeline
Transcoding is modeled as a directed acyclic graph — a set of tasks where arrows only point forward and never loop back (Facebook's streaming video engine works this way). The original splits into video, audio, and metadata, then tasks run in stages: one after another when a task depends on an earlier one, and side by side when they don't.
Common tasks: inspection (check the video is good / reject broken files), video encodings (different resolutions, codecs, bitrates), thumbnail, and watermark. The DAG is built from config files the content programmer writes, so different creators can get different pipelines (watermarks, custom thumbnails, HD or not).
Transcoding architecture
Preprocessor → DAG Scheduler → Resource Manager → Task Workers → Encoded Video
│
┌──────────┼──────────┐
Task queue Worker queue Running queue
- Preprocessor — splits the video into GOP (Group of Pictures) chunks, builds the DAG from config, and saves the GOP chunks + metadata in temporary storage so a failed encode can retry from saved data instead of starting over.
- DAG scheduler — breaks the DAG into stages of tasks and puts them in queues.
- Resource manager — runs three priority queues (task / worker / running). A scheduler picks the most important task, finds the best worker, sends it off, and watches it until it finishes.
- Task workers — do the actual DAG tasks (encode, thumbnail, watermark…).
- Temporary storage — metadata in memory, video/audio in blob storage; cleared once the work is done.
Mention GOP alignment and the DAG. They are the difference between "I'd transcode it" and "I'd split the video into independently-playable GOP chunks and run a configurable DAG of encode tasks across a pool of workers, retrying from cached segments." That depth is exactly what interviewers are digging for.
Step 4: Deep-dive — optimizations
Speed
| Optimization | How it helps |
|---|---|
| Parallel uploads | The client splits the video by GOP, so chunks upload at the same time and can resume after a failure |
| Upload centers near users | Use CDN edges as upload points (US, Asia…) so the first hop is short |
| Message queues everywhere | Decouple the stages — the encoding part no longer waits on the download part; it just reads events and runs on its own |
Safety
- Pre-signed URLs — the client asks the API for a short-lived link that grants write access to exactly one object, then uploads straight to it. Azure calls this a Shared Access Signature.
- Protect content — DRM (FairPlay, Widevine, PlayReady), AES encryption with an access policy, or a visual watermark.
Cost (the big one)
YouTube views follow a long-tail distribution — a few videos get most of the views, and a huge number of videos get almost none. Use that fact:
- Serve only the most popular videos from the CDN; serve the rare ones from cheaper, high-capacity storage servers.
- Don't pre-encode every version for unpopular content — encode short videos only when someone asks for them.
- Only send regionally-popular videos to the regions that actually watch them.
- At huge scale, build your own CDN and connect directly with ISPs (this is what Netflix Open Connect does).
Error handling
Recoverable vs non-recoverable. A failed transcode segment → just retry it a few times. A broken video file → stop and return an error code. Per-component plan: upload error → retry; split error → fall back to splitting on the server; resource-manager queue down → use a backup copy; worker down → retry on a new worker; API server down → it's stateless (keeps no per-user memory), so just send the request elsewhere; DB master down → promote a replica to take over.
Wrap-up
You've designed a video platform: uploads go straight to blob storage with pre-signed URLs, a GOP-chunked DAG transcoding pipeline re-makes the video, two blob stores are wired together through a completion queue, the CDN is tuned to keep cost down on the long tail, and playback adapts to the viewer's internet speed from the nearest server.
If time is left, point at the extensions: scale the API tier (it's stateless, so adding more servers is easy), scale the DB (replication + sharding), live streaming (same upload/encode/stream backbone, but tighter timing, less parallel work, and stricter error handling), and video takedowns (catch copyright or illegal content at upload or through user flagging).
Pacing for 45 minutes: 5 min on requirements + the two sizing numbers → 10 min on high-level (upload
- stream flows) → 20 min on deep-dives (transcoding DAG, then the cost long-tail) → 10 min on optimizations + failure modes. The two flows and the DAG are the core; everything else is depth you add if there's time.
Practice
Check that you understood the upload, transcode, and stream journey.
1. What does transcoding do?
2. Why does the raw upload skip the API servers and go straight to blob storage?
3. What is a DAG in the transcoding pipeline?
4. Why serve only the most popular videos from the CDN?
5. What happens when the viewer's internet connection gets weaker?