What Happens When You Press Upload on YouTube

A recent LinkedIn post by Rocky Bhatia sketched how YouTube's backend might work in nine steps: upload flow, caching, metadata, web servers, user data, services, recommendations, adaptive learning and observability. It was a clear overview, and it also cited no sources. That made me curious which parts are documented, which are plausible and which are simply guesses.

So I went to primary sources: YouTube's own help pages, Google's documentation, the Vitess project, Google's research paper and reporting on Google's hardware. Here is what holds up, what does not, and how to tell the difference.

1. Upload→
2. Process (SD first)→
3. Transcode→
4. Many formats→
5. Deliver→
6. Store and recommend

Transcript

Press upload on YouTube, and a lot happens before anyone watches. A recent LinkedIn post sketched it in nine steps. Here's what I could confirm from primary sources, and what is still a guess. First, processing. YouTube's help pages say a video can be published once the SD version is ready. HD and 4K come later. A sixty minute 4K video at thirty frames a second can take up to four hours. Transcoding is expensive, so Google built a chip for it. Argos has ten encoder cores per chip, and two chips per board. Google reports twenty to thirty-three times better compute efficiency than its earlier software setup. Each video then exists in many formats: different resolutions, different codecs. YouTube says its Auto setting changes quality to suit your viewing conditions, so the stream can step up or down while you watch. Delivery comes next. Google Global Cache puts servers inside internet providers' networks. Google says typically seventy to ninety percent of cacheable traffic can be served from them. The data layer hit limits early. In twenty ten, YouTube created Vitess for MySQL. First a primary and a replica, then more replicas, then sharding, with a proxy routing queries to the right shard. What runs today isn't public. Recommendations follow a two stage design, described in a twenty sixteen Google paper. A deep model narrows the catalogue to candidates, then a ranking model scores them. What I couldn't confirm: the exact serving path, the cache layers, and today's recommendation models. Those are plausible, not documented. Treat every diagram of this, including mine, as a sketch. So: process, transcode, deliver, store, recommend, and know which parts are documented. Follow for more breakdowns, with sources.

Processing: standard definition first

YouTube's help pages say a video can be published once its standard-definition version has been processed. Higher qualities, such as HD and 4K, take longer and become available when processing finishes. The page gives a concrete example: a 60-minute 4K video at 30 frames per second can take up to four hours to finish its high-resolution version. Processing time depends on the format, length, frame rate, quality and how busy YouTube is.

Transcoding: a custom chip

Compressing video into many formats is expensive on ordinary CPUs, and newer codecs such as VP9 and AV1 need even more computing power. Google's answer was dedicated hardware: Argos, a video coding unit built for YouTube. Each chip has ten encoder cores and two chips sit on each board. Google claims a 20 to 33 times improvement in compute efficiency over its previous optimised system, which ran software on traditional servers.

Two cautions. That number is Google's own, repeated by press coverage; the primary source is Google's ASPLOS 2021 paper, which I have not benchmarked. And the chip is a hardware detail, not the whole pipeline.

Formats: many versions of every video

Each video then exists in many resolutions and codecs, so it can play on many devices and connections. YouTube's help page describes the Auto quality setting as changing to give you the best experience for your viewing conditions, which is why the picture can step up or down while you watch. I have not found YouTube's exact encoding ladder or segment lengths documented, so I will not claim them here.

Delivery: servers inside internet providers

Google Global Cache lets internet providers serve certain Google content from inside their own networks. Google says typically 70 to 90 percent of cacheable traffic can be served from these caches, though hit rates vary with each network's usage. Google's page describes "certain Google content" and does not name YouTube specifically, so I describe it that way too.

Data: the MySQL story

The Vitess project's history page is the most useful primary source here. Vitess was created in 2010 to solve the MySQL scalability challenges the YouTube team faced. The progression was a primary database for writes and a replica for reads, then more replicas as read traffic grew, then sharding when writes outgrew the primary. Early on, the application had to know which shard to ask; Vitess moved that routing out of the application and into a proxy.

That is history, not a description of today. What YouTube runs now is not publicly documented, so I keep it in the past tense.

Recommendations: two stages

The 2016 paper "Deep Neural Networks for YouTube Recommendations" by Paul Covington, Jay Adams and Emre Sargin describes a two-stage design that is typical of large retrieval systems. A deep candidate generation model narrows the whole catalogue to a smaller set, and a separate deep ranking model scores those candidates. It is the best available description, but it is a decade old and not a map of today's system.

Documented versus guessed

Part	Status	Source
SD processed first, HD and 4K later	Documented	YouTube Help
Argos transcoding chip	Documented (efficiency figure is Google's)	Google, press coverage
Auto quality changes with conditions	Documented	YouTube Help
Google Global Cache inside ISP networks	Documented (not YouTube-specific)	Google GGC help
Vitess created for YouTube's MySQL in 2010	Documented as history	Vitess project
Two-stage recommender	Documented in a 2016 paper	Google Research
Exact request path (DNS, load balancer, web and app servers)	Not documented	none found
Cache layers inside YouTube, notification design	Not documented	none found
Today's recommendation models and observability stack	Not documented	none found

Why bother checking

System design is a habit of asking what breaks first. The same habit applies to the diagrams you learn from. Separating the documented from the guessed makes the real lessons clearer: process the cheap version first so people can publish quickly, spend hardware where the cost is, put popular bytes close to viewers, and split a database before it breaks. Those lessons hold even where the exact implementation is private.

Further reading

• YouTube Help, Low video quality after upload and Change the quality of your video: processing order and the Auto setting.
• Google, Introduction to Google Global Cache: how GGC works and the 70 to 90 percent figure.
• Vitess, History: why Vitess was created at YouTube.
• Covington, Adams and Sargin, Deep Neural Networks for YouTube Recommendations (RecSys 2016).
• 9to5Google, Google's Argos video coding unit: the chip and Google's efficiency claim.
• Rocky Bhatia's original LinkedIn post that prompted this check.
• My notes on the AI side of the same habit: How AI Agents Actually Work.