A look at how YouTube works. YouTube streams 500-plus hours of uploaded video every minute, to 2.5 billion monthly viewers, in resolutions from 144p to 8K. The architecture split that makes it possible: a heavy one-time upload pipeline that turns each video into dozens of pre-transcoded variants, and a thin playback path that serves from CDN edge with almost zero origin traffic.
How YouTube Works: The problem at scale
YouTube’s two-sided problem is brutal: creators upload raw video at every quality from phone-camera 480p to professional 8K, in every codec invented since 2005; viewers watch on everything from a 2G phone in rural India to an Apple Vision Pro. The same video has to play instantly on all of them, without buffering, while adapting to the viewer’s bandwidth in real time. And the recommendation surface (what to show next) has to surface the right video out of billions in under 100ms per click. The system has to optimize two unrelated objective functions: per-viewer playback smoothness and session length.
The core architecture
The upload and playback paths are deliberately separate. Upload: when a creator uploads, raw bytes land in Google Cloud Storage. A transcode pipeline (millions of worker tasks running on Borg, Google’s internal cluster manager) fans the video out into a matrix of resolutions (144p through 8K) and codecs (H.264, VP9, AV1), each chunked into small segments for adaptive streaming. The metadata (title, description, tags, watch graph edges) goes into Bigtable, chosen for its single-digit-millisecond random reads at YouTube’s query volume. Playback: a viewer’s app requests a video, the catalog returns the manifest (a DASH or HLS playlist listing every resolution/codec available), and the player picks the highest stream the network can sustain at that moment. The segments themselves come from Google’s CDN, the Google Front End layer, with edge caches in nearly every country, populated on demand by popularity.
The transcode pipeline is the cost center
The reason YouTube invests heavily in codecs (VP9, then AV1) is storage and bandwidth: a single minute of 4K raw is ~4 GB; the same video at AV1 in 4K is ~100 MB. Across 500 hours of upload every minute, that ratio is the difference between petabytes and exabytes per day of stored video. The transcode pipeline runs on free compute (the same clusters Google would have to run anyway for Search), which is why YouTube can afford to keep legacy 240p transcodes of 2006 videos online forever. The marginal storage cost is near zero.
Adaptive bitrate is why playback feels instant
The player doesn’t pick a resolution and stick with it. It maintains a buffer of a few seconds, samples the current download speed against the bitrate of each available resolution, and shifts up or down as the network changes. Start low (144p) for the first segment to get video on screen in under a second, then ramp up if bandwidth holds. This is why a video starts playing instantly even on a bad connection, and why it visibly sharpens a second or two in. The protocol (DASH for desktop and Android, HLS for Apple platforms) is invisible to the user but is the reason no one complains about “YouTube buffering” anymore. That complaint used to be constant.
Recommendations are the harder ML problem
The catalog (Bigtable) and CDN handle playback. The recommendation system (what video appears next in your home feed or in autoplay) is the part that actually drives watch time. Google’s published papers describe a two-stage model: a candidate generator that pulls a few hundred plausible videos out of billions based on your watch history and similar users’ behavior, then a ranker that scores each candidate on predicted watch time, satisfaction surveys, and click-through rate. The ranker is retrained continuously. The feature engineering is what every other video platform has spent a decade trying to copy.
The one non-obvious insight
YouTube’s architecture has almost no overlap with Google Search’s, despite both being Google’s flagship products. Search is a giant inverted index over web text, queried by keyword. YouTube is a giant object store of pre-transcoded video files, queried by video ID. The two share infrastructure (Borg, Bigtable, the Google network) but not data model. This is why YouTube and Search feel like products from completely different companies. Operationally, they are.
YouTube is the canonical example of pre-compute-once, serve-from-edge. Heavy work happens at upload time (transcode matrix) and popularity time (CDN edge). Playback is thin. Recommendations are the part that actually moves watch time, and that’s where the engineering depth lives.