How YouTube Actually Works

Every minute, more than 500 hours of video get uploaded to YouTube. That single uploaded file doesn't stay one file for long it gets sliced, converted into a dozen different formats and resolutions, spread across a tiered storage system, and eventually cached on servers sitting physically close to whoever's about to watch it. All of that has to happen fast enough that a video can be watchable within moments of finishing its upload, at a scale most platforms in this series would consider genuinely intimidating.

This article looks at how YouTube is actually built the pipeline a video travels through after you hit upload, the sharding system YouTube built and open-sourced specifically to keep an old, familiar database scaling to planetary size, and the two-stage neural network quietly deciding what plays next after your current video ends. YouTube doesn't publish a dedicated consumer-facing engineering blog the way some platforms in this series do, so this draws on detailed independent technical breakdowns, YouTube's own open-source projects, and Google's own published research, including the team's original recommendation-system paper.

What Happens the Instant You Hit Upload

A detailed breakdown on DEV Community walks through the pipeline a video enters immediately after upload: the raw file gets processed through transcoding, converting it into multiple formats and resolutions to support different devices and connection speeds. A companion piece on Women Who Code fills in the next step once transcoding finishes, the processed video files move into object storage, and a dedicated "completion server" gets notified, saving the video's metadata into a database so the rest of the system knows this video now exists and is ready to be found and played.

A publishing house that receives one manuscript and, before it ever reaches a bookstore shelf, produces a hardcover edition, a paperback edition, a large-print edition, and an audiobook all from that same single original source captures the same idea. One upload becomes many different renditions, each suited to a different kind of reader, or in YouTube's case, a different device and connection speed.

You hit "Upload"
  → Raw video file received
  → Transcoding: converted into multiple resolutions and formats
      (different codecs, different bitrates, for different devices)
  → Transcoded files saved to object storage
  → Completion server notified
  → Video metadata saved to the database
  → Video becomes discoverable and playable

Why Transcoding Isn't a One-Size-Fits-All Job

A more detailed guide on Grokking the System Design describes this transcoding step as running in parallel using custom hardware Video Coding Units, or VCUs built specifically for this purpose rather than relying on general-purpose processors. The same guide notes the output includes multiple codecs entirely: H.264, VP9, and increasingly AV1, with the system automatically detecting what a given viewer's browser or device actually supports and serving the most efficient option available. A separate breakdown on Rocky Bhatia's Substack reports that AV1 specifically can reduce bandwidth needs by roughly 30% compared to the older H.264 standard a meaningful saving once multiplied across YouTube's entire CDN footprint.

The same DEV Community breakdown makes a further point worth calling out: transcoding is computationally expensive, so the system optimizes by processing popular content more aggressively presumably generating more format variants, at higher quality tiers while content with limited viewership gets simpler treatment. A tailor who takes exceptional care fitting a suit for a client who'll wear it constantly for years, while offering a simpler, faster alteration for a costume that'll be worn once for a single afternoon the effort invested scales with how much use the finished product is actually expected to get.

Tiered Storage: Not Every Video Deserves the Same Shelf

Here's a detail that mirrors a pattern seen elsewhere in this series. The same Grokking the System Design guide describes a multi-tiered storage strategy: the hottest content recently uploaded videos, or those with steady, ongoing views lives in Google's distributed file system at petabyte scale, while old, rarely-watched videos get pushed onto cheaper HDD or tape storage, where access might take seconds to minutes rather than being instant, in exchange for a dramatically lower cost per gigabyte. A separate breakdown on Krishil Agrawal's blog adds the top of this hierarchy: the top 1% of videos by view count get stored directly on SSDs at CDN edge nodes, delivering sub-50-millisecond access and reportedly handling around 80% of all YouTube's total traffic from that small sliver of especially popular content.

A grocery store keeping its best-selling items right at the front on easily reachable shelves, its steady, moderately popular stock in the main aisles, and its rarely-requested specialty items in a back room that takes an employee a minute to retrieve from nobody stores milk and a niche imported spice on the same kind of shelf, because they don't get requested anywhere near the same amount.

Top 1% most-viewed videos → SSDs at CDN edge nodes → sub-50ms delivery
                              (handles ~80% of all traffic)
 
Recent uploads / steady views → distributed file system → petabyte scale
 
Old, rarely-watched videos → HDD or tape → seconds-to-minutes access,
                              very low cost per gigabyte

Vitess: Teaching an Old Database a New Trick

This is genuinely one of the more interesting engineering stories in the whole platform. A breakdown on Krishil Agrawal's blog explains that Vitess is an open-source sharding middleware, originally developed by YouTube itself, that sits between application code and MySQL handling query routing, connection pooling, and horizontal sharding transparently, letting a genuinely old, well-understood relational database scale to millions of queries per second without application code needing to be rewritten around that complexity.

Here's the deeper problem this actually solves: MySQL, on its own, was never built to be split effortlessly across hundreds of physical machines. Sharding a database by hand usually means every single piece of application code that talks to that database needs to somehow know which specific shard holds the data it's looking for. Vitess exists specifically to hide that complexity, sitting as a layer in between so the application can keep writing simple, ordinary-looking queries, while Vitess handles the genuinely hard part of figuring out where that data actually lives and routing the query there correctly.

A large hotel chain's central reservation phone line, where a customer just says which city and dates they want, without ever needing to know which specific physical hotel branch, out of hundreds worldwide, actually has their exact room booked the routing complexity is fully absorbed by the reservation system itself, invisible to the person just trying to book a room. Vitess plays that same role between YouTube's application code and the underlying, physically-sharded MySQL databases holding the platform's metadata.

Without Vitess:
  Application code → needs to know exactly which shard
                      holds a given piece of data → complex, brittle
 
With Vitess:
  Application code → simple, ordinary-looking query
    → Vitess → figures out the correct shard, routes the query there
  → Application never needs to know sharding exists underneath it

The same source notes MySQL data things like video titles, descriptions, thumbnail URLs, and creator information gets horizontally sharded via Vitess by a hash of the user ID or video ID, and critically, supports live resharding without downtime, meaning the underlying shard layout can be reorganized as the platform grows, without ever having to take the whole system offline to do it.

Keeping the Rest of the Data Ecosystem From Falling Over

It's not just one database doing all this work. The same Krishil Agrawal breakdown describes a genuinely varied data ecosystem, each piece chosen for a specific job: an in-memory cache achieving roughly a 90% hit rate for hot data like view counts and session state, using consistent hashing so that when a cache node changes, only a small fraction of keys need to be remapped specifically avoiding a "cache stampede," where losing one node would otherwise suddenly dump a huge wave of requests directly onto the underlying database all at once. A separate system, optimized for high-volume time-series writes, handles watch history and engagement analytics, while Kafka sits in front of all of it absorbing sudden write spikes millions of views can buffer safely in a queue while downstream processing systems consume them at a pace they can actually sustain, rather than being overwhelmed the instant a video suddenly goes viral.

The same source adds a resilience layer sitting over the whole thing: YouTube's infrastructure spans multiple Google Cloud regions, with every critical service running in at least three of them simultaneously meaning if an entire data center fails outright, traffic fails over to a healthy region via Anycast DNS within seconds, rather than causing a visible, platform-wide outage.

A city's emergency dispatch system routing calls to whichever nearby fire station can respond fastest, and instantly rerouting to the next-nearest station if one happens to be unexpectedly out of service the caller never needs to know or care which specific station ultimately responds, only that help arrives quickly regardless of which single station might be having a bad day.

The Two-Stage Brain Deciding What Plays Next

Here's the part of YouTube most people interact with constantly without ever thinking about the machinery behind it: the recommendations feeding your homepage and the autoplay queue after a video ends. The foundational description of how this actually works comes from Google's own published research a 2016 paper by Covington, Adams, and Sargin, titled Deep Neural Networks for YouTube Recommendations, which a technical summary on The Morning Paper explains established the two-stage approach still widely used across the recommendation systems industry today.

The system splits into two entirely separate neural networks, according to the same summary. First, a candidate generation model narrows YouTube's enormous overall corpus hundreds of millions of videos down to just a few hundred plausible candidates for a specific user, based on their watch history and other coarse signals. Then, a separate ranking model takes that much smaller shortlist and scores each candidate individually, with the highest-scoring videos actually surfacing as what you see.

A large company's initial resume screening process, where an early, faster review filters thousands of applicants down to a shortlist of a few dozen genuinely plausible candidates, before a slower, far more careful and detailed final interview round decides who actually gets the job among that much smaller, pre-filtered group running the expensive, detailed evaluation on every single applicant from the very start would be far too slow and costly; narrowing the field first, cheaply, is what makes the more careful second stage actually feasible at scale.

Millions of videos in YouTube's entire corpus
  → Candidate Generation model (fast, broad)
    → narrows down to a few hundred plausible candidates
      → Ranking model (slower, much more precise)
        → scores each candidate individually
          → Highest-scoring videos are what you actually see

A more recent explainer on Vozo notes this same underlying two-stage approach now powers several different surfaces across the app Home, Up Next, search ordering, and Shorts each with a subtly different objective, whether that's starting a new viewing session, extending a current one, or directly answering a specific search query. A summary on PyImageSearch adds an important detail about how the ranking stage is actually trained: rather than optimizing for simple click-through rate, which tends to reward misleading, clickbait-style thumbnails and titles that a viewer clicks but doesn't actually finish watching, the model is explicitly trained to predict expected watch time a signal that captures genuine engagement far more honestly than a click alone ever could.

Putting It Together

None of the individual pieces here are exotic inventions on their own. Video transcoding pipelines are common across the streaming industry. Tiered storage based on access frequency is a well-established pattern. Two-stage recommendation funnels are now widely adopted well beyond YouTube itself, as later research on similar systems at companies like LinkedIn and Pinterest has shown. What makes YouTube's engineering story genuinely compelling is the sheer range of specialized systems working in concert custom transcoding hardware, a database-scaling tool built in-house and later open-sourced for the rest of the industry to use, and a recommendation engine trained specifically to reward honest engagement over clickbait all coordinating to make an upload watchable within moments and a recommendation feel personally relevant within milliseconds.

What This Means Going Forward

As YouTube keeps expanding into short-form video, live streaming, and increasingly real-time interactive features, the same underlying tensions covered in this article keep resurfacing in new forms: how do you keep transcoding fast and cheap as upload volume keeps climbing, how do you keep a decades-old relational database technology scaling gracefully rather than replacing it outright, and how do you keep a recommendation system honest about what "engagement" actually means as the platform's formats keep multiplying. The lesson underneath YouTube's story isn't really about Vitess, VCUs, or two-stage neural networks specifically. It's the same one running through this entire series: the systems that manage genuinely impossible scale rarely do it with one single breakthrough they do it by building the right specialized tool for each individual piece of the problem, and trusting those pieces to work together.