Design YouTube

11:04am. It works.

One server. One video file sitting on its disk. Someone clicks play, the server reads the file and streams it back.

50 people are watching. Nothing is on fire.

Hold onto this picture, because everything that follows is this exact system refusing to stay this simple. The interview question "design YouTube" is not asking you to invent something clever. It is asking what you do, in order, as this picture stops working.

Press play on the simulation and watch it cope.

2:30pm. It gets shared, and the wrong thing breaks.

The video gets posted somewhere with an audience. 50 viewers becomes 5,000.

Now, your instinct from every previous lesson is to add servers behind a load balancer. That instinct is wrong here, and knowing why is the whole point of this question.

Do the arithmetic that actually matters. A modest 1080p stream is about 5 megabits per second. 5,000 concurrent viewers is 25,000 megabits per second, which is 25 Gbps. A normal server has a 1 Gbps network card.

You are short by a factor of twenty-five, and CPU was never the problem. The server is not thinking too hard, it is trying to push bytes through a pipe that is too narrow. Video is a bandwidth problem wearing a compute problem's clothes.

Adding app servers gets you more CPU you did not need, each still stuck behind its own 1 Gbps card. You could add 25 of them, and you would be paying 25 times over to solve the wrong bottleneck.

2:47pm. Stop serving the bytes yourself.

The fix is to stop being the one who sends the video at all.

Move the file off your server into object storage, then put a CDN in front of it. Now when someone in Jakarta presses play, the bytes come from a CDN point of presence in Jakarta, over a network built for exactly this, and your server never sees the request.

Your server's job shrinks to something almost embarrassing: hand back the page and a URL. That is a few kilobytes. It can do that for 5,000 people without noticing.

Why this works so well here: a video file never changes. Once encoded, it is the same bytes forever. That makes it the most cacheable thing in computing, and 5,000 people watching the same trending video means one CDN fetch from origin and 4,999 edge hits.

This is why the ratio matters so much. The first viewer in each region is expensive. Everyone after them is nearly free.

6:15pm. Somebody uploads a video.

Watching is solved. Now the other half of the system shows up, and it has the opposite shape.

Someone uploads a 2 GB file. It cannot be served as-is. It has to be transcoded into the ladder of formats real playback needs: 240p for a phone on a train, 1080p for a laptop, chunked into segments so the player can switch quality mid-stream. That work takes minutes of CPU per video.

If the upload request does that work inline, the user's browser sits on an open connection for eight minutes and then times out. And your one poor server is pinned the entire time, serving nobody.

So do not do it inline. Accept the file, drop a job on a queue, return "upload received, processing" immediately. A pool of workers pulls jobs off that queue and transcodes at its own pace. Finished renditions go to object storage, ready for the CDN.

Look at what you have now: two systems, not one. The read path is bandwidth-bound, spiky, and cacheable. The write path is CPU-bound, slow, and async. They have almost nothing in common, and they scale on completely different signals. Saying that sentence out loud is the thing that makes an interviewer sit up.

What you traded, and what you build now.

Say these out loud in an interview and you sound like someone who has run a system, not read about one.

What you traded: the CDN buys enormous bandwidth for the price of staleness, which is free here because video files never change (you re-upload rather than edit). The queue buys a fast, reliable upload for the price of the video not being watchable the instant it lands, and every upload UI on earth shows a "processing" spinner because everyone made this trade.

What you would do with more time: pre-generate thumbnails in the same worker pass; scale the worker pool on queue depth rather than CPU, since depth is the leading indicator; keep only popular renditions warm at the edge and let the long tail come from origin.

The one-line version: serving video is a bandwidth problem you push to the edge, and ingesting video is a CPU problem you push to a queue. Almost everything else is detail.

Now build the watch path. 200 requests per second are coming in. An app server handles 40, an origin handles 80, and a CDN edge absorbs thousands. Keep the origin alive.