Design YouTube / Netflix

Assume 800 million daily viewers who watch about 45 minutes each, and creators who upload 400 hours of video every minute. The average upload is 10 minutes long and arrives at about 10 Mbps. Delivered streams average 2.5 Mbps once you mix phones and televisions.

The write side is a pipeline. The upload service accepts parts directly into an originals bucket and, once the last part is verified against the file hash, drops a job on a queue. An orchestrator turns that job into a graph of tasks: inspect the file, split it into segments, encode each segment into each rendition, check quality, package and publish. Encoders are a large, mostly stateless fleet, much of it on cheap preemptible machines, because every task can simply be retried.

The read side barely touches our data centres. The playback API is a small service that checks permissions, picks a CDN and returns a signed manifest URL. From then on the player fetches a few kilobytes of manifest and then a steady stream of 4-second segments, almost all of them from an edge cache inside the viewer's ISP. Misses go to a regional shield that protects the origin, and only the shield ever reads the renditions bucket.

First the orchestrator inspects the original: duration, frame rate, resolution, audio tracks, whether it is HDR. Then it splits the video into chunks of roughly 10 seconds, cutting only at keyframes so each chunk decodes on its own. A 10-minute upload becomes 60 chunks, and each chunk becomes an independent task per output rendition. With 8 renditions that is 480 small tasks that can run on 480 machines at once, so the wall-clock time is bounded by the slowest chunk, not the length of the video.

Each encoder writes its output with forced keyframes every 2 seconds, so that every rendition has segment boundaries at exactly the same timestamps. That alignment is what lets a player switch from 720p to 1080p between two segments without a glitch. A packaging step then wraps the encoded chunks into CMAF segments of 4 seconds, which both HLS and DASH players can read, and writes one manifest per format that lists every rendition.

Every upload gets an H.264 ladder, because every device can decode it. Higher-efficiency codecs are added later and only when a video earns them.

Most uploads are watched a handful of times. Encoding all of them in AV1, which costs many times more CPU than H.264, would waste most of that work. So the pipeline is tiered. Every video gets the fast H.264 ladder. Once a video passes a watch-time threshold, a second pass re-encodes it in VP9 or AV1, which cuts the bytes per hour by 30 to 50%. For the few videos with very large audiences, it is worth going further: per-title or per-scene encoding runs trial encodes at several bitrates, scores them with a perceptual metric such as VMAF, and picks the cheapest bitrate per rung that still looks right. A cartoon may need half the bits of a handheld concert video at the same resolution.

Quality checks run on every chunk before packaging. Encoders occasionally produce corrupted output, especially on preemptible machines that are reclaimed mid-write. A chunk whose duration, frame count or quality score is off is re-encoded instead of being shipped to millions of screens.

The player downloads the manifest, starts at a conservative rung so the first frame appears quickly, and measures how fast each segment arrives. It keeps a buffer of 10 to 30 seconds and moves up the ladder when throughput and buffer allow, down when the buffer drains. Because segments are aligned across rungs, switching costs nothing but the next request. Starting fast matters more than starting sharp: viewers abandon a slow start far more than a soft first few seconds.