Design Youtube - System Design Interview

Lets design the high-level architecture of youtube - similar to how we'd tackle this in a system design interview.

0:00 - Intro
0:15 - Background
1:30 - Functional Requirements
1:55 - Non-functional Requirements
5:35 - High-level Design
14:08 - Design Details
17:00 - Youtube video playback example
20:30 - Protocols

design youtube
design netflix
design hulu
design video streaming
system design interview
distributed systems
object storage
vitess
database sharding

#system #design #interview

[NeetCode]

Let me know if you guys want more system design content - I've been wanting to do more and have a lot of ideas, so hopefully you all are interested! Let me know, and feel free to drop a like 👍 =)

[aelam]

Neetcode! I've been applying to jobs for 7 months now since my graduation and struggled to get interviews as my resume was fairly unimpressive. I kept telling myself that I just needed to make sure that I killed any interview I DID get and your channel is what helped me to do just that. Got an offer today that blew my expectations out of the water. Thanks for all you do for all of us and keep it up!

[Brucewayne]

Thank you Mr beast for system design 😊

[xanderthunder]

Awesome Video! Thank you for going into detail and explaining what every part of an example systems architecture is accomplishing and why it's useful. One little nitpick -> (22:00 ) you say YouTube is using TCP which is (for quite some time now) not true anymore. If you look closely at the "client-protocol" used to send the video/audio data (you show that at 18:29 ) you will see that YouTube is using QUIC (HTTP3) which is built on top of UDP instead of TCP. It includes most of the functionality of TCP based HTTP protocol but is technically not using TCP.
Just wanted to point that out in case anyone was wondering...

Great video though, keep up the neet work!

[muzamilahmed]

I think you've missed most points in the watching part. User can change the resolution for that we need multiple videos. Also, different OS will have different file formats like iOS, and android. so if there are 4 resolutions with 3 formats, 4*3=12. Each video should be stored as 12 different videos. Also, we need to store videos in chunks in the cloud storage. We will use main Dash File which contains all the video's information like chunk number, url to that chunk. So, if user skips to the 4th chunk, we'll check the dash file to get the url for the 4th chunk and will make the request for that particular chunk having specific resolution and format.

[eswarprasad]

The fact that YT isn’t streaming a data source in complete but making HTTP requests to load chunks of video/audio and taping them at the client end

BLEW MY MIND !!! my whole life seems like a lie, lol
Great video, Thanks mate

[jahmed]

Bro! Genuinely such eye opening content. Thank you! I am no where near solving problems like this yet but it's really helpful getting exposed to all the realistic considerations involved in designing large scale systems.

[varshasingh]

We want more system design video...I love all your videos ❤️

[imrajsingh]

such beauty looking at all the different high level trade offs and considerations going into designing an application that I have been using daily for the past 15 years

[victorz]

First video recently that I haven't skipped for one second. Great work!

[shuysnoopy]

These types of videos are such a blessings since it goes deep into a particular usecase or several design descisions which would be rather difficult to gain experience. I can try to learn as many frameworks as possible, do as many projects as possible, but if I dont have such real-world (or close to real-world) lessons like these I might be making mistakes that aren't so visible to the naked eyes.

[jessicakoch]

seriously your explanations of complex topics are amazing, i’m so glad i found you! I was going cross eyed looking at graphs on Leetcode and their explanations were not helpful at all. Officially subscribed, thank you so so so much!

[jasonswift]

Yes, we need it. Hope to have other content appear in the course, such as machine learning, data analysis.

[sina]

You can easily have a user service and store all of the users information including the uploader there, hence you don't need to have it stored alongside the video but just have a userId as reference. This way you have decoupled your systems and follow a more domain driven design and if the user data changes you don't need to go through 1000 of videos just to update a profile picture. At the beginning of every system design interview/document you'd better write down your domains in order to see what are the different services you need before jumping into the design.

[biro]

On the profile picture updating async, you could always solve that by referencing a latest.png and then only updating the object store to change latest.png to reference to the newest image and hence the changes would propagate much faster than updating 1000x video documents

[sameer_sah]

2:14- Reliablity is defined as ability of a system to work as per specification inspite of extenal (high loads) or internal (faults) factors. If our non-functional requirement is videos to not disappear after upload, we are essentially looking for the system to be durable (not reliable).

[bumq]

Getting into system design and one of the best vids I've seen so far, great in depth detail

[akultyagi]

First i thought why is MrBeast is teaching system design lmaooo

[shanecoleman]

For things like the user profile photo, I wouldn't think you'd store that in each video document. The document should contain a reference to the profile photo. Each user can only have one profile photo, so this is fine.

[CookieCurls]

There’s a lot of issues in this video. Durability instead of reliability, no explanation for how videos get from the object store to the CDN, NoSQL not being the best option for metadata, caching videos at the app server being a bad idea in general when you have a CDN, apparently saving profile picture URLs in the video metadata instead of just making a separate request for user data, etc.