News · New this week
YouTube system design: chunked upload to adaptive bitrate
Chunked upload, a queue, encoders, a CDN and an adaptive bitrate player. Why video goes blurry on a slow network instead of stalling.
The interview question is simple: how does YouTube play smoothly even on a slow connection, like a local train? The answer is a pipeline, and each step exists because the naive version breaks.
This is the standard interview design. It is not YouTube's own internal system.
The naive version and where it fails
The first instinct is to keep the video in one place and let everyone read from it. That works until millions of viewers show up. The one place chokes.
So the design has to satisfy three things. The upload shouldn't break, the video should play at any speed, and there should be no buffering.
Upload and storage
The phone sends the video in chunks, and the upload is resumable. If the network drops, only the unfinished chunk is sent again, not the whole file. On a flaky connection that is the difference between a retry and starting over.
The chunks land in object storage, which the reel calls a cheap godown. Storing big videos in a database is expensive, so the database isn't the place for them. The object store holds both the raw files and the encoded ones.
Queue and encoders
One uploaded video has to become many versions. That is heavy work, so it goes into a queue, a line of encode jobs processed in order.
Encoders are the workers. They pick jobs off the line and produce qualities from 144p up to 4K, then save the results back to the object store. Because the work sits in a queue, a burst of uploads waits its turn instead of knocking anything over.
CDN and the player
Now the choke problem comes back. A viral video would hammer the object store. A CDN fixes that by pulling a copy from storage once, caching it, and serving viewers from nearby. Storage sees one request, and the viewers get the video from close to their city.
The last piece is the player. It measures your speed every few seconds, picks from the available qualities, fetches the next chunk at that quality, and plays it. That loop is measure, pick, fetch, play, and it is called adaptive bitrate.
When the network slows, the player picks a lower quality for the next chunk. The picture gets blurrier, but playback keeps going. That is why the video blurs and doesn't stop.
What to take from it
Next time you sketch this in an interview, walk the flow in order and give the reason for each box: chunked upload, object storage, queue, encoders, CDN, adaptive bitrate. Then try the reel's closing question on yourself. When the player chooses a quality, would you go by measured speed or by how much buffer is left?
