How YouTube Was Able to Support 2.49 Billion Users With MySQL

#48: Break Into Vitess Architecture (4 minutes)

Neo Kim

May 31, 2024

Get my system design playbook for FREE on newsletter signup:

This post outlines Vitess architecture. If you want to learn more, find references at the bottom of the page.

Share this post & I'll send you some rewards for the referrals.

Note: This post is based on my research and may differ from real-world implementation.

Once upon a time, 3 people working for PayPal decided to build a dating site.

Yet their business model failed.

So they pivoted to create a video-sharing site and called it YouTube.

They stored video titles, descriptions, and user data in MySQL.

As more users joined, they set up MySQL in leader-follower replication topology to scale.

Leader-Follower Replication Topology in Mysql — Leader-Follower Replication Topology in MySQL

But replication in MySQL is single-threaded.

So followers couldn’t keep up with fresh data on extreme write operations to the leader.

Yet their growth rate was explosive.

And hit a whopping billion users to become the second most visited site in the world.

So they scaled out by adding a cache and preloaded all the events from the MySQL binary log. That means the replication becomes memory-bound and faster.

Although it temporarily solved their scalability issue, there were new problems.

Here are some of them:

1. Sharding:

MySQL must be partitioned to handle storage needs.

But transactions and joins become difficult after sharding.

So application logic should handle it.

This means application logic should find what shards to query.

And that increases the chance of downtime.

2. Performance:

The leader-follower replication topology causes stale data to be read from followers.

So application logic must route the reads to the leader if fresh data is necessary.

And this needs extra logic implementation.

3. Protection:

There’s a risk of some queries taking too long to return data.

Also too many MySQL connections at once can be problematic.

And might take down the database.

Vitess MySQL

They wanted an abstraction layer on top of MySQL for simplicity and scalability.

So they created Vitess.

Here’s how Vitess offers extreme scalability:

1. Interacting with Database:

They installed a sidecar server in front of each MySQL instance and called it VTTablet.

Vttablet Running as a Sidecar Server — VTTablet Running as a Sidecar Server

It let them:

Control MySQL server and manage database backups
Rewrite expensive queries by adding the limit clause
Cache frequently accessed data to prevent the thundering herd problem

2. Routing SQL Queries:

They set up a stateless proxy server to route the queries and called it VTGate.

Vtgate Routing Queries to a Specific Shard — VTGate Routing Queries to the Specific Shard

It let them:

Find the correct VTTablet to route a query based on the schema and sharding scheme
Keep the number of MySQL connections low via connection pooling
Speak MySQL protocol with the application layer
Act like a monolithic MySQL server for simplicity
Limit the number of transactions at a time for performance