Chapter 14: Design YouTube

Welcome to Last Minute Lecture.

This free chapter overview is designed to help students review and understand key concepts.

These summaries supplement, not replace, the original textbook and may not be redistributed or resold.

For complete coverage, always consult the official text.

Welcome back to the Deep Dive.

Today we are really tackling a monster.

We're going to design the core of a global video streaming platform, basically the blueprint for something like YouTube.

Our mission here is to really distill the core architecture,

the absolute non -negotiable constraints and some of the brilliant engineering tricks that they use to handle this kind of insane scale.

And when you say insane scale, that's not an exaggeration.

Just look at the numbers from a few years back.

You're talking two billion monthly active users.

Two billion.

Five billion videos watched every single day.

Generating what?

Over $15 billion in ad revenue.

They're not just some web server.

It's a global machine built to handle a flood of data and do it reliably and maybe most importantly cheaply.

Absolutely.

So let's set the scope here because we can't possibly design everything.

The comment section, recommendation algorithms,

playlists, I mean that's a whole other can of worm.

A different deep dive for another day.

Exactly.

So for this one, we're zeroing in on just two fundamental things.

The ability to upload a video and the ability to watch or stream a video.

That's it.

Make sure both are fast and reliable.

And focusing like that, it immediately gives us our core constraints.

You know, we need to support everything, mobile, web,

smart TVs.

It's got to be global.

It needs high availability, massive scalability and reliability.

And this is a big one.

We're being told we have to leverage existing cloud infrastructure.

So content delivery network, CDNs and blob storage.

And that last point relying on the cloud.

That's so critical because it brings us straight to the big hidden challenge here.

Money.

Ah, yes.

Costs.

The back of the envelope calculation we're about to do is it's the ultimate reality check.

It proves that you can't just tack on cost optimization at the end.

That has to be the primary driver from day one.

It really, really is.

Let's just run some quick numbers for you.

Let's say only five million users.

A tiny fraction upload one medium sized video a day, maybe 300 megabytes.

The system needs to find 150 terabytes of new storage every single day.

And that's just for the storage.

But the real killer isn't storage.

It's the egress, right?

The cost of data leaving the network.

That's the CDN bill.

That's the one that'll get you.

If you're two billion users watch, say, an average of five videos a day, you are moving petabytes of data across the globe.

So what does that cost?

Well, if we use a super simplified average CDN cost, and this is often the biggest line item of maybe, I don't know, two cents per gigabyte transferred, you're looking at something like a quarter of a million dollars per day just in streaming costs.

So if you build this thing without cost baked into every single decision, you're going to bankrupt the platform.

It's that simple.

OK.

That makes perfect sense.

So with that financial gun to our head, the high level architecture almost designs itself.

We know we can't build our own global storage or custom CDN faster or cheaper than Amazon or Google.

No way.

I mean, Netflix and Facebook learned that the hard way a decade ago.

So architecturally, that means we're splitting the work into three main blocks.

You've got the client, which is just your phone, your browser, your TV.

Then you have the CDN, the huge globally distributed network that's just built to store and fire video files at users as fast as possible.

And finally, you have the API servers.

They're the brains of the whole operation.

They handle everything else.

User sign up, creating those secure upload links, updating the database, running the recommendation engine, all the metadata.

So we need to see how these blocks actually work together.

The sources lay out two really critical workflows,

the video uploading flow and the video streaming flow.

Let's start with the hard one.

Getting a video into the system.

Let's talk components.

Let's try to picture it.

A user hits upload.

That request goes through a load balancer to one of our many API servers.

In the back end, we've got a super fast metadata cache and a more permanent metadata database.

This is for titles, view counts, you know, with the video file actually lives.

And we also need two kinds of storage.

First is the original storage.

That's where the raw huge video file lands first.

It's what we call BLOB storage binary large object.

Just think of it as a big, cheap digital garage for the original file.

Okay, so original storage and then?

Then there's transcoded storage.

That's where the final polished streamable versions of the video will live.

And the magic that happens in between is done by the transcoding servers.

To manage all this, all this stuff happening at different times, we need a completion queue, which is just a message queue and a completion handler to process those messages.

The real genius here is parallelism.

The second you hit that upload button, two completely separate processes kick off at the same time.

They're totally decoupled.

Okay, so flow A.

This is the actual video file, the data.

The raw video gets uploaded and dumped into that original storage you mentioned.

Right.

And that's the trigger.

The transcoding servers see that new file, they grab it, they start processing it.

And when they're done, two things happen at once.

The finished transcoded video files get pushed to the transcoded storage and then out to the CDN.

And a little completion message gets dropped into that completion queue, a little note that just says, hey, this job is done.

And while all of that heavy lifting is happening,

that's flow B, the context.

The client is sending all the metadata, the title, description, tags straight to the API servers, which immediately update the cache in the database.

Exactly.

And that completion handler, its only job is to watch that queue.

As soon as it sees a finished processing message, it grabs it, finds the right record in the database and updates it with the final streamable URL from the CDN.

So only then does the user get a notification saying your video is live.

Right.

And that decoupling is key.

The user isn't stuck on a loading screen waiting for a massive video to encode just to see that their title and description saved correctly.

That makes a ton of sense.

No.

Okay.

So now let's talk about the payoff.

Streaming.

People use the words streaming and downloading interchangeably, but they're fundamentally different things.

Oh, totally.

Downloading means you have to get the entire file before you can press play.

Streaming is, it's like a conveyor belt.

You're continuously getting small chunks of data, just enough to start playback right away.

And the system is just trying to stay ahead of you, keeping your buffer full.

And to make that conveyor belt work on all the different devices out there, you need standardized streaming protocols.

The sources mention things like MPEG -DASH and Apple HLS.

Yeah.

You don't need to get bogged down in the details, but the key takeaway is that these protocols are necessary standards.

Without them, your iPhone might support one format, your Android another, your TV a third.

They ensure everything just works.

Yeah.

The high level view of streaming is actually pretty simple then.

The streaming just happens directly from whatever CDN edge server is physically closest to the user.

And that's the genius of it.

That minimal distance means super low latency, which is the number one thing you need for a good viewing experience.

No buffering.

But the real complexity, the whole reason we have that entire flow A with transcoding servers, it all comes down to why we need to encode in the first place.

Why bother taking a perfectly good video file and converting it?

It all comes down to four things, cost, storage, compatibility, and user experience.

First, storage and cost.

Raw video files are gigantic.

An hour of HD video can be hundreds of gigabytes.

Transcoding compresses that file like crazy, which shrinks your storage bill and your delivery cost.

Okay.

Second is compatibility.

We kind of touched on that.

If you only have one video format, half your users might not be able to play it.

Right.

Third is adapting to quality.

You can't just blast a 4K stream at someone on a shaky 3G connection.

So you transcode into multiple resolutions, 720p, 480p, and so on.

So the system can pick the right one for the user's network.

And that leads to number four, which is probably the most important for the user experience.

The ability to switch quality on the fly.

You walk from your living room with Wi -Fi into the basement where you only have one bar of cell service.

The player needs to be able to switch from 1080p down to 360p smoothly without interrupting the video.

That can only happen if all those different versions already exist, ready to go.

And when we talk about an encoded file, there are two parts to it, right?

The container?

Yeah.

The container is like the box.

It holds the video, the audio, the metadata.

That's your .mp4, your .av file.

And inside the box are the codecs.

And the codecs are the compression algorithms themselves, like H .264.

Exactly.

They do the actual work of shrinking the data.

Now we get to the really mind -bending part, the transcoding architecture.

Encoding is computationally brutal, it's super expensive, and creators want options.

Watermarks, thumbnails, different audio.

How do you manage that complexity?

You manage it with something called the Directed Acyclic Graph, or the DAGE programming model.

Okay, DAGE.

This is the key insight.

Instead of one long, rigid process, a DAG breaks the job down into lots of little independent tasks.

Some can run in parallel, some have to run in sequence.

The whole point is that at this scale, you have to assume things will fail constantly.

The DAG lets you just retry the one tiny piece that broke, not the whole hour -long job.

So if I'm picturing the graph,

the original video comes in the top, and it splits into different paths.

Audio goes one way, video goes another, metadata a third, and then you have these little nodes, these tasks like insect file, encode to 1080p, encode to 480p, generate thumbnail.

Exactly.

And to manage this, the architecture has these really sophisticated roles.

It starts with the preprocessor, this thing is critical, it splits the video into independently playable chunks called a group of pictures, or GOPs, then it generates the specific D needed for that video.

And crucially, it saves those GOPs in temporary storage so you can easily retry a failed task.

So if the 720p encoder fails, you don't have to start from the very beginning.

The system just grabs the preprocessed GOPs and tries that one little job again.

You got it.

Then, the DAG scheduler takes that graph and starts feeding the tasks to the resource manager.

The resource manager is like the air traffic controller.

It's juggling thousands of tasks and thousands of worker machines, making sure the highest priority job gets the best available worker.

And the task workers are just the computers that do the actual work.

Running the watermark algorithm, compressing the video, merging the audio back in.

They use temporary storage, a mix of super fast memory and cheaper blob storage before spitting out the final file.

The whole thing, this entire complex dance, is all about speed and saving money.

And there are specific optimizations that make it work at scale.

Let's run through them.

Speed optimization number one.

Parallel uploads.

The client device itself, your phone, splits the video into those GOP chunks before it even starts uploading.

That's huge.

It means if your connection drops, you don't have to start the whole upload over from zero.

It just picks up with the last successful chunk, and you can upload multiple chunks at once.

OK, number two.

Proximity.

You don't want someone in Japan uploading to a server in Virginia.

So you use your CDN to set up upload centers all over the world, Asia, Europe, North America.

So users are always uploading to a machine that's physically close.

And tying it all together is the loose coupling.

We use message queues everywhere.

The download part of the system doesn't wait for the encoding part.

It just drops a message in a queue and moves on.

Maximum parallelism.

Now, safety.

This is a big one.

How do you let millions of random users upload files into your secure cloud storage without giving them the keys to the kingdom?

The pre -signed URL mechanism.

This is really clever.

The client never gets permanent credentials.

Instead, it asks the API server, hey, I want to upload a file.

The API server generates a special one -time use URL that grants temporary permission, maybe for 15 minutes, to upload one specific file to one specific location.

So it's like a temporary access pass.

Very smart.

And once the video is live, we have to protect it from being stolen.

The sources list three main ways.

First is digital rights management or DRM things like Google Widevine or Apple Fair Play.

Second is simple AES encryption.

The video data is scrambled and only decrypted when a logged -in authorized user hits play.

And third, visual watermarking, which you'll notice can be added as just another one of those simple tasks in our DAG workflow.

OK, let's circle back to that terrifying number from the beginning.

That quarter million dollar a day CDN bill.

This is where the long -tail problem comes in.

Yes, this is the cornerstone of cost savings.

The idea is that a tiny percentage of your videos get 99 % of the views.

Those are the hits.

The vast majority of videos, the long -tail, get very few views or even none at all.

So you treat them differently.

You have to.

First, only the most popular hot videos are served from the expensive super -fast CDN.

The long -tail stuff gets served from cheaper, slower, internal video servers.

That alone saves a fortune.

Second, for those unpopular videos,

you don't waste money in storage creating a dozen different encoded versions.

Maybe you only store one or two or for short videos, you don't even encode them until someone actually requests to watch it for the first time.

Third, regional popularity.

If a video is only popular in South America, don't pay to store copies of it on servers in Asia.

Keep the data close to the demand.

And finally, for the biggest platforms,

the ultimate move is to just build your own CDN or partner directly with internet service providers to get cheaper bandwidth rates.

It's all just a game of calculated efficiency.

Okay, last thing.

Errors.

In a system this big, things will break.

What's the strategy?

You basically split errors into two camps.

Recoverable and non -recoverable.

A recoverable error, like a transcoding job failing for a random reason, you just retry it a few times.

A non -recoverable error, like a user uploading a corrupt video file, you just stop the process until the user something went wrong.

And resilience is built in everywhere.

The API servers are stateless, so if one dies, traffic just goes to another.

If a database master fails, you promote one of its slaves.

If a worker machine dies, mid -encode.

The resource manager just assigns the task to a new worker, which picks up right where the old one left off using those GOPs from temporary storage.

So we've designed a system built on horizontal scaling,

extreme parallelism, and just ruthless cost control.

If we had more time, we'd dive into how you scale the database itself with sharding to handle billions of records.

But the architecture we built today for video on demand is actually very different from what you'd need for live streaming, and that comparison, I think, is a really interesting final thought.

Oh, absolutely.

Live streaming has much, much tighter latency requirements.

A few seconds of delay is a big deal.

It often uses different protocols, and you have way less opportunity for parallelism because the data is coming in in real time, not as a big batch file.

So you can't just retry a failed encoding job that takes 30 seconds?

No.

The moment is gone.

It forces you to make completely different choices about everything from buffering to how you handle errors.

It's a whole different beast.

A perfect reminder that in any massive system, the design is always driven by the core constraint, whether that's latency or, in our case today, cost.

Thank you for diving into these sources with us.

Hopefully next time you hit play on a video, you'll think about the incredible complex dance that happens in the background just to get that stream to you cheaply and reliably.