Future Scaling and Vitess

In one line: Vitess is a real system YouTube built and open-sourced, and it exists because of a problem every growing product hits — sharding works, and the complexity of sharding in application code eventually does not.

What has to scale

As YouTube scales, we must scale:

• Web and application servers
• Datastores
• Load balancers (at every layer)
• Distributed caches

Three of these are easy and one is not — which is why only one gets a solution

Web servers, load balancers, and caches all scale by adding boxes. They are stateless or hold replaceable state, so capacity is a purchasing decision.

Datastores are different, because they hold state that must stay correct while you redistribute it. That is why the rest of this lesson is entirely about the database and says nothing further about the other three.

Worth recognizing as a general pattern: in almost every system, the stateful tier is the one that limits you. Lesson 6 already named MySQL as the component that breaks first, and this is the follow-through. When asked "how does this scale?", the useful answer is about the stateful tier — everything else is procurement.

Why hand-rolled sharding fails

Sharding improves performance but adds complexity to the application logic and threatens ACID (Atomicity, Consistency, Isolation, Durability) properties.

Sharding pushes database problems into application code, and they get harder there

Sharding a relational database by hand means the application now owns things the database used to handle:

Routing. Every query must determine which shard holds its data — so every call site needs the sharding key and the mapping, and a mistake means querying the wrong shard.

Cross-shard joins. A join spanning shards can no longer be a join. The application fetches from each shard and joins in memory — losing the query planner, the indexes, and any hope of efficiency.

Cross-shard transactions. This is the ACID threat. A transaction touching two shards needs two-phase commit or has to abandon atomicity. Most applications quietly abandon it, which means partial failures leave inconsistent state.

Resharding. When a shard outgrows its machine, splitting it means moving live data while serving traffic, and every client's mapping must update in step.

Each is individually manageable. Together, spread across a large codebase where every developer must get it right, they become unsustainable — the failure is organizational, not technical. The logic is correct in a hundred places and wrong in the hundred-and-first.

Vitess

Vitess abstracts the complexity of a sharded MySQL deployment by presenting a logical single-database interface to clients. Under the hood, it coordinates a cluster of MySQL instances. It manages sharding and query routing while maintaining MySQL compatibility and transactional (ACID) guarantees. This enables horizontal scalability while minimizing the need for sharding logic in the application layer.

The application talks to VTGate as if it were one MySQL. VTGate consults the topology service for the shard map, routes or scatters the query, and gathers the results. VTTablet sits in front of each MySQL instance handling pooling, query rewriting, and failover. The sharding logic lives in exactly one place.

The key move is putting the sharding logic in one place instead of a thousand

Vitess does not eliminate any of the problems above. Routing, cross-shard queries, and resharding all still happen — they happen inside Vitess rather than scattered through application code.

That relocation is the entire value:

• One implementation to get right, maintained by people who specialize in it, rather than every developer reimplementing routing at every call site.
• Applications keep speaking MySQL, so existing code, ORMs, and tooling continue to work — which is what makes adoption feasible on a large existing codebase.
• Resharding becomes an operational task performed by the proxy layer, not a coordinated code change across every client.

This is the same shape as several earlier decisions: distributed caching's configuration service centralizing server-list knowledge, object storage's manager node centralizing placement. When correctness depends on every caller doing something right, move it behind an interface where it only has to be right once.

Where Vitess sits on the scalability-versus-structure spectrum

The design places Vitess on a spectrum between structured relational databases and scalable NoSQL stores.

The usual trade is stark: relational gives you joins, transactions, and schema at the cost of horizontal scaling; NoSQL gives you scaling at the cost of relational features. Most systems pick a side.

Vitess is an attempt to occupy the middle — MySQL semantics with horizontal scale — and it does so by accepting a real constraint: it works best when queries stay within a shard. Cross-shard operations remain possible and remain more expensive, so the sharding key must align with the dominant access pattern.

That is a familiar requirement. The Blob Store chapter partitioned by full path so listings stayed local; pub-sub chose partition keys so related messages stayed together. Pick the shard key so the common query touches one shard, and the middle ground works; get it wrong and you have a distributed join engine.

Why denormalization is rejected as the alternative

Data denormalization is not a viable alternative to Vitess because it degrades write performance, which becomes critical as the system scales.

Denormalization is the usual escape from expensive joins — duplicate data so reads touch one place. It is the right answer in plenty of read-heavy systems.

It fails here because YouTube's metadata tier is write-heavy. Every view, like, comment, and subscription is a write, and duplicated data means every write fans out to every copy. Lesson 1 established the read-heavy asymmetry for video bytes; the metadata tier does not share that shape.

That distinction is worth making explicitly, because it is counter-intuitive: the same system can be read-heavy in one tier and write-heavy in another, and an optimization that is obviously right for one is wrong for the other.

Custom web servers

At YouTube's scale, default configurations of general-purpose web servers may not meet performance and optimization requirements. A custom server stack enables workload-specific optimizations that are difficult to achieve with standard deployments.

Note: ESF is a custom web server developed by Google. It is widely used in the Google ecosystem because standard solutions could not meet YouTube's performance needs.

You can inspect this yourself:

Building your own web server is almost always wrong — and this is the exception that proves the rule

For essentially every system, writing a custom web server is a catastrophic use of engineering time. nginx and its peers are extraordinarily well optimized.

It becomes defensible only when a fraction of a percent of efficiency is worth millions of dollars, which requires scale most systems never approach. At 12 Tbps, a 1% improvement in serving efficiency is 120 Gbps of capacity — real money, every month, forever.

The generalizable rule: custom infrastructure is justified when your scale makes a marginal improvement worth more than the engineering cost of achieving it. That is a calculation, not a preference, and for almost everyone it comes out against building.

Lesson 4's Lighttpd-versus-Apache discussion is the same reasoning one rung down — pick the right off-the-shelf tool first, and only build when even the right tool is insufficient.

Interview signal by level

Next: how the encoding actually works.