You're just in time for coffee today.

I wanted to give you a technical rundown of systems designed interview concepts that you need to know to aid your job.

Interview.

So the system's design interview usually doesn't have to do so much with coding.

People don't want to see you write actual coat, but little snippets here and there, and they really want to know how you glue a entire system together.

And that is part of the job interview, especially for senior engineers.

So usually in the Suffer Engineering interview, you may have three coaching sessions, one behavior and then one systems designed for senior candidates.

You may even have two systems.

Is that interviews like what I had over at Facebook when I interviewed there, and it's very open ended.

It's a chance for you to show your expertise and dive into any area that you want to.

It's not really about the language and syntax, which is why a lot of engineers who focus on primarily like which language they should know that's not going to come into play here is really about the frameworks, the FBI's that design patterns, how you may put the entire system together and that architectural portion, and the lot of it may have to do with scalability as well and coming up with good design choices there.

So to help you all out, I wanted to run.

They're some of the top concepts that you may need to know for your system since I interview.

So why don't we get started now?

The 1st 1 is load balancing Quick pass Computer science may be hard for a holiday.

Shopping doesn't have to be spread the love of computer science by gifting a loved one.

A brilliant premium subscription.

This really excites me because it's such a fun way to nurture care us, the bill confidence and the Philip problem solving skills crucial to school, job or career.

So help your loved one spark a lifelong love of learning, get 20% off premium and brilliant that work slash tech lead.

So load balancers usually help to distribute traffic too many different Web servers in order to help with throughput late unsee scalability.

So, for example, when the user accesses your website instead of hitting a single computer and it could take the single hosting machine down, for instance, you can put a load balancer in front of that request and then that load balancer will rout the client request to a number of different Web servers and you can set the rules for how this load balancer will function.

Now there are various techniques for load balancing.

One is you can use specialized software like engine X, where you can write your l request to many different I.

P addresses host machines which can actually serve to request another popular technique which I like to use personally is I just used the n s load balancing were given a your L website.

You can have that website resolved to a number of different I P addresses, and the benefit of this is is very simple.

You don't need any machines, but then you don't have much customize ability in here as well.

You can said that bruise for a load, balancing like round Robin has you on the I P address or figuring out which mission has the least load and the signing traffic to that machine, figuring out which missions are offline and removing traffic from those all sorts of techniques here.

So that's the first technique is a very simple one.

But the thing to know is usually your Web server is not the first to go down.

In fact, quite often is your database server, which may be under high low for lots of rights or REITs.

And in order to handle that, that brings us to our second concept, which is cashing quite often.

You'll be hitting the database very hard.

You may be doing a bunch of sequel joints and quarries, but, for example, the front page of The New York Times they have to go into that day.

The baseball is the same data for every single user for each day.

So is that what you can do is insert cashing layer and cash.

The results of that request this is a in memory cache is a very faster access.

It doesn't have to hit that this at all, which makes it efficient.

And you can just have that cash last for like, say, 24 hours or so.

Some common cashing surfaces.

Airmen cashed reddest Cassandra.

I've seen all of them used in production before.

At large tech companies, Facebook uses man cash quite a bit, and it's a very common technique now, speaking of cashing, we can also use seed Ian's content delivery networks to cash Stab that asset files like images.

JavaScript files html.

CSS files video files.

Usually anytime you see a image of video, it is being served through a CD in which is a global network of servers, which can cast your content.

And this serves a number of purposes.

Number one.

It decreases the load on your actual servers so that people around the world can access your images or videos, and it won't take down your servers.

But the second critical aspect this it makes accessing your content very fast for your users who maybe around the world and then the CD ends.

They're located geographically near these people all across the world, so that people can access your content quickly.

It makes a big difference if your website rap is able to load fast and see the answer fairly easy to set up.

One common technique is using the poor technique where the first time a user accesses your file, it may be slow because the CD and has actually fetch your file and then cash it.

But then, after that, for all subsequent users within that vicinity, that local region.

Then the access is going to be very quick, and another technique is pushed where you can actually push your files under the CD and such that it would be fast, even for the first access.

But usually that has some higher upfront costs, because then you may be storing files on CDs that may not be used necessarily.

And if you love users to upload images, thank you may want, like a distributed file system, maybe something like Amazon s three now in the system's design interview.

It's not uncommon that ought to be asked to design the database scheme about what people's you may be using, you know, like, what are the primary case going to look like?

And what are your indices Now?

They debased indexes are important because they make your quarters fast.

For example, if you're designing a dating app and you want all of the users who are active within your neighborhood, then your quarry is going to need to be indexed by the users, say latitude and lunch Dude, with their date last active right, and that compound index essentially crazed like binary tree of your users sorted by the ladder to longitude and then their day active.

And that allows you to issue a quarry like that.

You may also want additional indexes, for example, like you could have another index on set just last active.

So you could get this Of all of the users globally who are less active now, Even with these indices, though, as we mentioned, one of your first point of failure will be the database.

And back in the day when I would be building APS, my database would be under so much load that what you have to do after that is you used replication.

So you have, like, slave master replication in This said that you have a single master database where you ran into, and then it is essentially cloned that duplicated into many slave databases, where you only read from you can configure database to act as a slave and replicate from another host master machine.

And as is bringing in the day that there may be like a one or two second delay, sometimes we just okay, sometimes you don't necessarily need consistent data.

So consistency is the concept where if you write to the database, then you immediately are able to read back the same value.

This may be important in certain scenarios.

Like, say, user up baster profile.

They want to see the changes reflected right away.

So then you could read from, say, the master database.

Or you could just read from a cash that's always up to date.

All right, so let's take a step back.

We have a number of techniques here for scaling out a Web application server, Right?

Usually you have a Web server, a database ever as a image server or videos over assets server, right?

The Web server.

You can scale out using low balancers, right, and you can just add as many Web servers as you want.

And then your load balancers are able to distribute low to these machines, so that sounds good for the image server and any static assets.

We can use content delivery networks to scale out to thousands of machines around the world, and that makes a fast for the database server.

We can use cashing indexes and replication.

We can have hundreds of cash in servers and slave servers and ordered the scale of our reads so that we can do as men you reach as we like, but what we haven't myself so far is database rights, for example, for application like Twitter, where you're writing into the database a lot.

So how do we handle that?

Where uses are hammering the database with new data, and you can use database charting where you split up the database into multiple Master Day.

The basis Now there are a number of ways to shut your database.

Vertical charting is where you take each table and just put it into a new machine.

So you may have, like a user table tweets table, a comments table.

A user supports table, a chat table, and each of these just are in different machines, and that can work for a while.

But what if you have a single tweets table and it's just going very large?

How do we handle that?

What?

That's words onto a starting where you take a single table and split that across multiple machines.

There a number of techniques for doing this, but one coming way is you take the user i d.

And you just model by the total number of machines that you want to allocate the user I d to.

So if you have, say, five master machines for his table, you just take these i, d Mont five and that Ross issues er to a different machine.

Now there are a number of complex these here, which we go over in more detail over in our program.

Tech Interview pro dot com, by the way, so I'll give a quick plug.

But we do have our entire systems design interview portion that covers all of these concepts in far more detail, along with systems design concepts for mobile developers as well.

So checked out if you're interested at Tech interview, product comes.

But as I was saying with horizontal starting, another technique at once did was I had this master table, which indicated for each user which machine they would be located on.

And this master table was responsible, essentially for the Chardon algorithm.

Now, in recent years, we've also seen no sequel databases coming up and no sequel databases.

They're not relational, so that means you pretty much can't do, say, range.

Corey's on them.

It's not like my sequel, but the good thing about them is they're essentially key value pairs.

So with these key value pair models, the's no sequel databases are naturally able to scale automatically by themselves across multiple different machines.

Easily some common no sequel engines.

Armando de be Amazon's dynamodb, or fire based fire store.

So pretty much you can use a combination of these techniques to scale out your application.

You can use a hybrid of thes maybe, for example, if you have active chest over, you could be easy and no sequel engine or simply in memory table.

And then for your more persistent needs like a user table, you could be using a standard relational database like my sequel event around the all out.

You often be asked about a P I design.

You know, you may have a client and server.

How do they communicate with each other?

What are the functions I met?

This they use?

What is the day?

The transport mechanism?

Are you using Jason or particle buffers?

What does that data look like?

How do you handle security?

Do you support offline usage?

How do you make it fast?

So as you can see, it's really open ended, and depending on the application and the usage scenarios and where your load is going to be.

No.

Two applications are going to scale exactly the same way, which is why it is important to ask a lot of clarifying questions and figure out what type of load and uses Justin aerials.

This system will be put under you never want to scale too early or put them premature.

Optimization is because it just complicates the system way too much.

And what people really value these days is simplicity.

The simpler you can keep the system, the better.

Now you can learn more about math, science or computer science that brilliant or slash tech lead.

Brilliant as a problem solving based website and app with a hands on approach with over 60 interactive courses, all live brilliance courses have storytelling, code writing, interactive challenges and problems himself.

They'll puzzle you, surprised you expand your understanding of the modern world, and brilliant premium is a perfect year for anyone on your list.

From ages 13 2 100 they have brand new interactive content that makes solving puzzles and challenges even more fun and hands on with brilliant.

You unravel concepts bit by bit and build up to understanding of our world.

So check Emma and get 20% of premium at Brilliant that orc slash tech lead.

So I hope I come for some of the key Concept Central's that you may need to scale up a Web applications over four systems.

Is I interview?

Let me know if you have any additional tips and tricks or questions.

Put him in the comments below.

Announce you there If you like the video, give you like and subscribe, and I'll see you next time.

Thanks, bye.