Systems Design Interview Concepts (for software engineers / full-stack web)

        Today I wanted to give you a technical rundown of systems design interview concepts that you need to know to ace your job interview so the systems design interview usually does not have to do so much with coding people don't want to see you write actual code but little snippets here and there and they really want to know how you glue an entire system together and that is part of the job interview especially for senior engineers so usually in the software engineering interview you may have three coding sessions one behavior and then one systems design for senior candidates you may even have two systems design interviews like what I had over at Facebook when I interviewed there and it's very open and 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 it's really about the frameworks the api the design patterns how you may put the entire system together and that architectural portion and a 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 through some of the top concepts that you may need to know for your systems design interview so why don't we get started now the first one is load balancing quick pause computer science may be hard but 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 chaos the build confidence and develop problem-solving skills crucial to school job or career so help your loved one spark a lifelong love of learning get 20% off premium at brilliant work slash tech lead so load balancers usually help to distribute traffic to many different web servers in order to help with throughput latency scalability so for example when the user accesses your web site instead of hitting a single computer and it can 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 route the client request to a number of different web servers and you can set up rules for how this load balancer will function now there are various techniques for load balancing one is you can use specialized software like nginx where you can route your L request to many different IP addresses host machines which can actually serve the request another popular technique which I like to use personally is I just use DNS load we're given a URL website you can have that website resolve to a number of different IP addresses and the benefit of this is very simple you don't need any machines but then you don't have much customizability in here as well you can set that bruise for load balancing like round-robin has Y on the IP address or figuring out which mission has the least load and assigning traffic to that machine figuring out which machines are offline and removing traffic from those all sorts of techniques here so that's the first technique and it's 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 load for lots of writes or reads and in order to handle that that brings us to our second concept which is caching quite often you'll be hitting the database very hard you may be doing a bunch of sequel joints and queries but for example the front page of the New York Times they have to go into that database but it's the same data for every single user for each day so instead what you can do is insert a caching layer and cache the results of that request this is an in-memory cache it's very fast to access it doesn't have to hit the disk at all which makes it efficient and you can just have that cache last for like say 24 hours or so some common caching services are memcache read as Cassandra 

       I've seen all of them used in production before a large tech companies Facebook uses memcache quite a bit and it's a very common technique now speaking of caching we can also use CDN content delivery networks to cache and static asset files like images JavaScript files HTML CSS files video files usually anytime you see an image or video it is being served through a CDN which is a global network of servers which can cache 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 is it makes accessing your content very fast for your users who may be around the world and then these CD ends they're located that geographically near these people all across the world so that people can access your content quickly it makes a big difference if your website or app is able to load fast and CDN store fairly easy to set up one common technique is using the pool technique where the first time a user accesses your file it may be slow because the CDN has to actually fetch your file and then cache it but then after that for all subsequent users within that vicinity that local region then the axis is going to be very quick and another technique is pushed where you can actually put your files onto the CD and such that it would be fast even for the first access but usually that has some higher upfront cost because then you may be storing files on CD ends that may not be used necessarily and if you allow users to upload images then you may want like a distributed file system maybe something like Amazon s3 

      Now in the systems design interview is not uncommon that ought to be asked to design the database schema about what tables you may be using you know like what are the primary key is going to look like and what are your indices now database indexes are important because they make your course 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 query is going to need to be indexed by the users say latitude and longitude with their date less active right and that compound index essentially creates like a binary tree of your users sorted by the latitude longitude and then their day active and that allows you to issue the queries like that you may also want additional indexes for example like you can have another index on say just less active so you could get a list of all of the users globally who are less active now even with these indices though as we mentioned one of your first points of failure will be the database and back in the day when I would be building apps my database would be under so much low that what you have to do after that is you use replication so you have like slave master replication in this setup you have a single master database where you write into and then it is essentially cloned duplicated into many slave databases where you only read from you can configure a 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 which is okay sometimes you don't necessarily need consistent data so consistency is the concept work 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 a user updates their profile they want to see the changes reflected right away so then you could read from say the master database or you can just read from a cache 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 server as a image server or video server asset server right the web server you can scale out using load balancers right and you can just add as many web servers as you want and then your load balancers are able to distribute load 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 it faster for the database server we can use caching indexes and replication we can have hundreds of caching servers and slave servers in order to scale out our reads so that we can do as many reads as we like but what we haven't myself so far is database writes for example for application like Twitter where you're writing into the database a lot so how do we handle that where users are hammering the database with new data and you can use database sharding where you split up the database into multiple master databases now there are a number of ways to charge 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 a tweets table a comments table a user support 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 well that's horizontal charting where you take a single table and split that across multiple machines there are a number of techniques for doing this but one common way is you take the user ID and you just modify the total number of machines that you want to allocate the user ID to so if you have say five master machines for a table you just take the user ID modified and that rusts each user to a different machine now there are a number of complexities here which we go over in more detail over in our program tech interview pro combat way so I'll give a quick plug but we do have an 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 check that out if you're interested at Tech interview procom but as I was saying with horizontal charting 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 queries on them not like my sequel but the good thing about them is they're essentially key value pairs so with these key value pair models these know sequel databases are naturally able to scale automatically by themselves across multiple different machines easily some common no sequel engines are MongoDB 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 these maybe for example if you have active chat server you could be using no sequel engine or simply an 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 and then to round it all out you often be asked about API design you know you may have a client and server how do they communicate with each other what are the functions and methods they use what is the date the transport mechanism are you using JSON or protocol 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's important to ask a lot of clarifying questions and figure out what type of load and usage scenarios this system will be put under you never want to scale too early or put in premature optimizations 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 at brilliant auric slash tech lead brilliant is a problem-solving based website and app with a hands-on approach with over 60 interactive courses all of brilliance courses have storytelling code writing interactive challenges and problems to solve they'll puzzle you surprised you and expand your understanding of the modern world and brilliant premium is a perfect year for anyone on your list from ages 13 to 100 they have brand-new interactive content that makes solving puzzles and challenges even more fun and hands-on with brilliant your unravel concepts bit by bit and build up to an understanding of our world so check Emma and get 20% off premium at brilliant Thorpe slash tech lead so I hope I cover some of the key concepts and tools that you may need to scale a web application server for systems design interview.

About Home Study

Technology and Life