Name: システムデザイン面接の考え方（ソフトウェアエンジニア向け／フルスタックウェブ (Systems Design Interview Concepts (for software engineers / full-stack web))
Uploaded: 2021-01-14T10:17:43.000Z
Duration: 11 min 5 s
Description: VoiceTubeの動画で発音を聞きながら英語表現を覚えよう！学べる英語：

程度の副詞

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

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.

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.

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

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.

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.

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.

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.

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?

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.

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.

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?

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.

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?

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.