Design YouTube
In December 2014 the view counter under Gangnam Style ran out of room. The video had passed 2,147,483,647 views, the largest number a signed 32 bit integer can hold, and YouTube had to move the counter to 64 bits. Nobody had planned for one video to be watched more than two billion times. That is the kind of problem this chapter is about.
You already know how to store and stream the video file itself. That is the video streaming chapter: upload in parts, transcode in chunks, serve segments from a CDN. This chapter is everything around the player. The number under the video, the subscriptions tab, the bell, the comments, and the copyright check that runs before anyone sees an upload. In an interview, "Design YouTube" is mostly these parts, and they are where the hard problems sit.
Step 1: Understand the problem#
"Design YouTube" is huge, so the first job is to agree on which part you are building. Ask these in the first three minutes.
| You ask | They say | What it settles |
|---|---|---|
| Is the video pipeline part of this, and the home page recommendations? | No. Assume upload, transcoding and playback exist. Treat the home page ranking as a service another team owns. | You can spend the round on the platform around the player. Say in one sentence how the pipe works and point at it, so the interviewer knows you are cutting it on purpose. |
| How big? | Assume a billion watch page loads a day. Some channels have hundreds of millions of subscribers. | The watch page is a read problem a cache solves. The big channels are what break a simple subscriptions feed, so they get their own deep dive. |
| How exact does the view count have to be? | Close enough, within a few minutes, for viewers. Exact, with fake views removed, for paying creators. | Two numbers from two pipelines: a fast one for display and a slow, careful one for money. This single answer shapes the whole counting design. |
| Who gets told when a channel uploads? | Every subscriber sees it in their subscriptions tab. Only those who turned the bell on get a push notification, within minutes. | Two different audiences of two different sizes. The feed can be slightly late, the push can be spread over a few minutes, and neither has to be instant. |
| How are comments ordered? | Top comments by default, newest first as an option. | Top order cannot be a sort at read time on a video with a million comments. It becomes a list you compute ahead of time. |
| Do we check uploads for copyright? | Yes. Match each upload against reference files that rights holders have supplied, before it goes public. | A gate in the publish path that can block a video or hand its money to someone else. How the matching works is its own system, so you design the gate, not the matcher. |
What you are building, and what you cut#
- The watch page: title, channel, counts, and your own state. One call that must be fast for a billion loads a day.
- View and like counts. Approximately right in minutes, exactly right by the next day.
- Subscriptions tab and bell notifications. A news feed with very uneven channel sizes.
- Comments, with top and newest ordering. Write light, read heavy, and very skewed.
- The Content ID gate before publish. A step in the publish path, with the matcher treated as a black box.
- Watch page metadata in under 200ms at p95.
- Displayed counts no more than a few minutes behind.
- Bell notifications delivered within about 10 minutes of publish.
- Counts used for creator payouts are exact and published daily.
- Upload, transcoding and the CDN. Covered in the video streaming chapter.
- Recommendations and the home page. A ranking system, and it belongs with the AI path.
- Search. The same shape as the web search engine chapter, over titles and captions.
- Live streaming and ads. Each one is its own design.
Back of the envelope#
Move the sliders. Watch which number grows fastest.
The watch page is 11,574 reads a second, and nearly all of them are the same few thousand popular videos, so a cache absorbs it. The heartbeats are 400 times the likes and every one is a write. That stream must never touch a database row directly, which is what the first deep dive is about.
Candidates average the views across all videos and conclude a counter column is fine. The average hides the shape. Ten million views of one trailer in its first hour is about 2,800 a second, all on one row. A single row in a relational database manages a few thousand updates a second at best before the lock queue becomes the bottleneck, and that is one video on one good day.
Step 2: Propose the high level design#
The API#
{ "value": "like" }{ "notify": "all" }The data model#
Three tables carry the platform. The first one shows the most important idea in this chapter: the row is the truth, and the count is something you work out from the rows.
| video_id | bigint | PK | Shard key, so every rating for one video lives together. |
| user_id | bigint | PK | One row per viewer per video. This is what makes a double like impossible. |
| value | enum | like, dislike or none. Unliking sets none rather than deleting, so the change is visible to the counting pipeline. | |
| updated_at | timestamp |
| subscriber_id | bigint | PK | The copy sharded by subscriber answers "which channels do I follow". |
| channel_id | bigint | PK | The copy sharded by channel answers "who follows this channel", which the fan out reads. |
| notify | enum | IDX | all, personalized or none, the three bell settings YouTube offers. Indexed with channel_id so the bell set is one range scan. |
| created_at | timestamp |
| video_id | bigint | PK | Shard key. Every comment on a video is on one shard, so loading a page of them is one query. |
| comment_id | bigint | PK | Time ordered, from the unique ID generator, so "newest first" is a plain range read. |
| parent_id | bigint | IDX | Null for a top level comment. Replies go one level deep, which keeps a thread to two reads. |
| author_id | bigint | ||
| body | text | ||
| state | enum | visible, held for review, removed. Hiding a comment is a state change, never a delete. |
YouTube kept its metadata in MySQL, and around 2010 a single database could no longer hold it. The team built Vitess, a layer that splits MySQL across many shards and sends each query to the right one, then open sourced it. It is now a CNCF graduated project used far outside Google. So "sharded MySQL" here is not a compromise, it is the real history.
The whole system on one whiteboard#
Figure 1 has three paths. The top row runs once per upload. The middle row runs a billion times a day. The bottom row is where the counts come from.
Walking Figure 1:
- The upload pipeline from the video chapter finishes transcoding and hands the video on. It is still private.
- Content ID compares the video's audio and picture fingerprints against the reference files rights holders have supplied. A match applies the owner's chosen policy: block the video, run ads and pay the owner, or just track it. Only then is the video published.
- Fan out workers write the new video's id into the subscription feed of every subscriber, for channels below a size threshold. Big channels skip this step (the second deep dive).
- Subscribers with the bell on get a push notification, sent out over a few minutes rather than all at once.
- A viewer opens a video. The watch API makes two calls in parallel: the shared part, which is the same for everyone, and the small personal part.
- The shared part comes from a Redis cache. For a popular video it is always there.
- On a miss, the cache loads the video's row from the metadata shard that owns it.
- Comments are loaded the same way, but only when the viewer scrolls down to them.
- The subscriptions tab reads the viewer's own feed list, filled in ahead of time by step 3.
The two dashed lines are the counting path. The player sends a heartbeat every 30 seconds, heartbeats and like changes go into the counting pipeline, and about once a minute the pipeline writes fresh counts into the cache. Writes like a new comment or a rating go through the watch API to their own tables, and are left off the figure so the read path stays readable.
Figure 1 never adds one to a view count in a database. Where does the number under the video actually come from, and what would go wrong if it were a column you updated on every view?
Step 3: Design deep dive#
Counting a billion views without a hot row#
Start with the obvious design, because the interviewer wants to hear you reject it. Every
view runs UPDATE videos SET views = views + 1. Each update locks the row, so updates to
one video queue up behind each other. On a normal video that is fine. On a trailer at
2,800 views a second, the queue grows faster than it drains.
Compare three places the +1 can go.
The log design gives you two numbers, and you should say so before you are asked. The display count is fast and roughly right: the stream job drops obvious repeats, such as the same session counted twice in a minute, and moves on. The payout count is slow and exact: the daily job has the whole day of events, so it can remove a session that watched 400 videos in an hour, or ten thousand views from one block of addresses. When the daily number is ready it replaces the display number. It is the same split as the ad click aggregator, for the same reason: money needs a careful count, and a screen needs a quick one.
What counts as a view? YouTube does not publish its rule, and you should not pretend to know it. A defensible answer: a view is a session whose heartbeats show at least 30 seconds of playback, or the whole video if it is shorter. Then say it is a product decision you would make configurable, because it will change.
For years, new videos on YouTube appeared to freeze at around 301 views while the real number climbed. The public count was held while YouTube checked that early views came from people, then released once the check finished. It is the two numbers idea, visible on the page, and in 2015 YouTube changed the system so counts updated more often.
There is one more trap inside the log design. Kafka spreads events over partitions using a key, and the natural key is the video id, because then one stream worker sees every event for a video and can add them up. Watch what happens to that key when one video gets most of the traffic.
Salt every key, or only the hot ones? Salting every video costs the extra adding step on millions of videos that get a few views a day. A common answer is to salt only videos the pipeline has seen go past a rate threshold in the last few minutes. I have not run this at YouTube's scale, so treat the exact threshold as something you would measure.
Subscriptions: one upload, 250 million subscribers#
The subscriptions tab is a news feed, and the news feed chapter already gives the answer: write the new post into each follower's list (push), except for accounts so big that the writes would take too long, which readers pull in when they open their feed. YouTube has more of those big accounts than most networks. India is YouTube's largest audience, and a few channels, T-Series among them, have passed 250 million subscribers. A channel like that cannot fan out with one write per subscriber.
YouTube adds one twist the plain news feed does not have: the bell. Here is one upload from a channel that size, step by step.
"How do you pick the threshold?" Do not guess a number and defend it. Say what it trades: below it you pay write work at upload time, above it you pay merge work on every read of the subscriptions tab. Start around 100,000 subscribers, then measure fan out lag and tab read latency and move the line until neither is the problem. Being able to move it without a deploy is the real requirement.
Comments: write light, read heavy#
A million comments on a video sounds like a write problem. It is not. A million comments in a day is about 12 a second, which one shard handles without noticing. The problem is the read: everyone who opens the video and scrolls down asks for the same first page of top comments, and "top" means sorted by a score that keeps changing.
Your own new comment is the one exception. If you post a comment and do not see it, you post it again. So the API puts the viewer's own recent comments at the top of their view, from the write it just made, even though the ranked list does not contain them yet. This is the same "read your own writes" fix the consistency article describes, done in the API instead of the database.
Break it#
A big film trailer goes live at noon on a channel with a lot of bell subscribers. Drag the dial and watch which box goes first.
Read every step as text
- normal noon · Healthy. The cache answers nearly every watch page. The metadata shards see a trickle of misses from the long tail of old videos. Counts lag by about a minute.
- pushes in one burst · Degraded. All bell notifications go out in the same minute. Millions of taps arrive before the watch API can add servers, so request latency rises. The cache is fine, because it was filled at publish. Spreading the pushes over ten minutes removes this spike.
- cache entry expires · Down. The trailer’s cache entry hits its expiry time at the peak. Every API server misses at once and sends the same query to the one shard that owns the video, thousands of times a second. That is a cache stampede. The fix is to let one request per key refill the cache while the others wait, and to refresh hot keys before they expire.
- counter frozen · Degraded. Heartbeats are keyed by video id, so the trailer’s whole stream lands on one partition. That partition falls twenty minutes behind and the view count stops moving on the most watched video of the day, which is exactly where people look. Salting the hot key spreads it out.
- repaired · Healthy. Pushes spread over ten minutes, one refill per key with early refresh for hot entries, and salted keys for hot videos. None of the fixes adds a new box. Each one changes when or where work happens.
The cache stampede is the one to raise without being asked. It only happens on your most popular video at its most popular moment, so it is the outage everyone sees.
Trade-offs#
| Choice | What you gain | What you pay | Pick it when |
|---|---|---|---|
| Count from a log, not a row | No lock on a hot row, one write per video per minute, and raw events kept for a careful recount. | The displayed number is a minute or two behind, and you run a stream job and a batch job instead of one UPDATE. | Any counter that a single item can push past a few thousand updates a second, or that money depends on. |
| Two numbers: display and payout | Viewers get a fast number and creators get an exact, fraud filtered one, each from the pipeline suited to it. | Two numbers can disagree for a day, and you must explain why a count went down when the recount removed fake views. | Whenever a count is shown in public and also paid out on. |
| Push for small channels, pull for big ones | Upload cost stays bounded for the biggest channels, and the subscriptions tab read stays one list plus a short merge. | Two code paths, and a threshold you have to tune and be able to change. | Any follow graph where a few accounts have millions of times more followers than the average. |
| Ranked comment list computed ahead | Reading top comments is a cache slice, not a sort over a million rows. | The order is up to a minute old, and you need a special case so people see their own new comment. | Any "top" ordering on a list that is read far more often than it changes. |
| Shared and personal watch page calls | The shared part caches for everyone, including at the CDN. | Two requests per page instead of one, and the client has to stitch them together. | Any page where almost everything is the same for every viewer and a few fields are not. |
Interview replay#
Checkpoint#
1. Why did Gangnam Style force YouTube to change its view counter in 2014?
2. Heartbeats are keyed by video_id in Kafka. One trailer gets a huge share of traffic. What is the fix?
3. Same design, but likes now decide a live vote and must be exact in real time. What changes first?
- 2,147,483,647. Gangnam Style broke the 32 bit counter in December 2014. Use 64 bit counters from day one.
- One row takes a few thousand updates a second at best. One trailer can pass that alone, so counts come from a log, never from +1 on a row.
- Two numbers. Display: approximate, minutes behind. Payout: exact, fraud filtered, daily.
- Push below the threshold, pull above it, and spread bell pushes over about ten minutes. The stampede is on the watch page, not the notification service.
I would cut the video pipe early, since upload, chunked transcoding and CDN delivery are a known design, and spend the time on the platform around the player. The watch page is split into a shared part that caches for everyone and a tiny personal part, so a billion loads a day mostly hit a Redis cache in front of sharded MySQL. View counts never touch a database row: the player sends heartbeats into Kafka, a stream job adds them up per video every minute and writes the total to the cache, and a daily job recounts the raw events with fraud filtering for creator payouts. Hot videos get a salted key so one trailer does not swamp one partition. Likes are one row per viewer, set with a PUT, and a change emits a plus or minus one event into the same pipeline. Subscriptions are a news feed: push into feeds for small channels, pull at read time for channels with hundreds of millions of subscribers, and send bell notifications over ten minutes so the watch page does not get a stampede. Top comments are a list ranked in the background, not a sort at read time. Content ID sits in the publish path as a gate. The failure I would call out is the trailer's cache entry expiring at its peak, so hot keys refresh early and only one request per key refills the cache.