Must Do System Design Questions

Key Takeaways

foreign live learning job opportunities a perfect way to level up yourself right hi everyone good evening how are we all on this fine evening just give me a thumbs up in the chat if i'm perfectly audible and visibility wall just give me a thumbs up in the chat so i am dhwani from geeksforgeeks and i will be your host for today i welcome you all to yet another session of geek summer carnival 2022. for those of you joining us for the very first time geek summer carnival 2022 is a summer carnival fiesta where you can avail amazing discounts on courses and services from gfg so today we have a very special guest with us it gives me immense pleasure to welcome swamiji bhattacharya hi swamiji hi uh it's it's it's a pleasure this side as well uh to join you and uh be a part of this webinar how are you i'm fine how about you i'm great too so for those of you watching us i'll give a basic introduction of thomajeet so swamijitsu is an experienced senior software engineer with a demonstrated history of working in the software product industry he is killed in java c plus plus and c and apart from this he also has a youtube channel where he regularly posts videos on lld interview experience mock interviews and much more so this is just a very basic introduction that i am giving we would be really happy if you're gonna like introduce yourself in your world sure uh hi pretty much everything is covered there so i am uh i am currently working as an sd2 at amazon and i have around four and a half years a little more than four and a half years of experience as of now and as you said i also have a youtube channel and there i constantly post regularly you know content around low level design be it interview experiences uh be to you know discussions about different companies and so on and so forth so that will be it for myself that's great i'm sure a lot of people in the audience already follow your youtube channel and know a lot about you so is there anything that you would like to share with our audience before we start this q a session uh nothing in job now nothing in general it's just that uh everyone i hope so everyone is staying safe uh even though yes you know in pandemic everything is dialing down but uh just stay safe for maybe a month or so and we can probably you know go back to normal i really hope so and on that positive note let's just dive into the questions the first question is that systems design is one of the most used concept in tech jobs can you elaborate on its importance and how it is you know like actually uh relevant in uh variance to the interviews that are conducted uh sure uh and that is probably a very true statement for example many of you guys must have you know heard or seen that hey you guys or software engineers do not regularly use dsa why they are asked in interviews and stuff like that however the case with system design is exactly opposite probably system design is something that you will be using from your day one uh onwards and that is the expectation as well uh from from a product standpoint it is extremely imperative that we uh do uh the design of the product uh whether or not the product will scale how much you know traffic is expected and on the basis of that what all uh components what all services what all infrastructure we should be uh building and scaling up these decisions uh do uh play an immense role in shaping how your product will continue and grow so from a product standpoint it is probably one of the most important things that one can learn and from an interview standpoint as well having said that yes in an interview it's a one hour interview you cannot expect to build a foolproof product in an interview but still the expectation is that you go through uh whatever you will be doing in your day-to-day job in that particular in that particular interview as a result system design becomes very very important uh from both interview as well as job purposes right so can a question have one set answer in system design and why uh no be it system design be it high level design weight low level design anything for that matter right these are extremely subjective in nature and it cannot uh have a set answer potentially i always say that every design is correct in some sense and wrong in some other sense there is always a trade-off that you take a trade-off between certain aspects to build a design as simple as that and you have to identify that trade-off so whenever you let's say you know you are giving a system design interview and you are designing a system do not worry that the system will be bad or system will or the design that you are building is bad or good but try to understand what trade-offs you are taking in order to build the system with the given components with the given infrastructure and why you are taking it that is important if you are able to highlight that in an interview then the interviewer will also know that hey even though maybe the system that the person designed is not completely accurate but the person or the person whoever you know the candidate knows the concepts behind different uh components that are being used and understands uh what are the trade-offs that they are taking and hence can be a better evaluation for that particular round so no there is no set answer for a system design question well that was a very detailed you know like a very to the point answer i'm sure a lot of answers are already like a lot of questions are already asked answered so can you tell us about the most frequently asked questions in system design any five of them so from a system design perspective like whenever someone asks me like what should i prepare for system design or what kind of questions i should uh prepare per se i typically say that whenever you are preparing for system design always always make sure that there is no set question per se but take up any application in your phone right just take up any application in your phone and see how you can design that particular system uh if you if you ask what are you know what uh what are some common system design problems that are discussed generally i can say maybe you know designing instagram designing a chat system like you know whatsapp uh that can be one uh designing instagram can be the other uh by instagram i mean basically there are several components in one particular product nowhere in an interview right i will you will be expected to design the complete product because that's simply not possible in a time frame of 45 minutes so generally the questions will be framed in such a manner that you will be potentially designing certain components of an entire product it can be a payment system that you are building it can be a notification system that you are building it can be you know the newsfeed generation system of let's say instagram or facebook that you will be building or the chat direct message system that you will be building so these are some of the uh most common uh aspects of a system design one one more common aspect of system design that actually requires you know understanding of certain you know intricate algorithms is basically um uber uber and how it basically localizes what different you know uh cabs are available around you and correspondingly gives you data in a seamless manner that is uh that is a bit different and it really requires you uh having an understanding of you know specific algorithms per se which definitely one should try out before an interview at least so here i have a question personal question like i heard what you're talking so is systems design the basic layout of the app like the blueprint or the actual you know like some big you poured some part of the app and you presented as a you know like uh like some part of the problem you have actually coded and you show that to the interviewers so uh system design typically can be of two parts one is your low level design and the other one is your high level design if we are talking about the low level design it essentially comprises of two three things or the low level design will comprise of your class design that you will be creating for or handling the data for that particular system right you will be having certain classes you will be having certain dependencies certain services that you will be creating and so on and so forth second aspect of a low level design will come with database design right obviously if you are handling data you will be storing the data somewhere so database design will also become an important part of low level design and the third aspect of low level design comes in the form of api design because again you will be creating classes you will be creating services those services will be interacting with one another so you should also have apis so that your front end can communicate appropriately with your back and then correspondingly api design comes up becomes an important part of low level design so if you are uh being asked a little low level design question this three is the expectation sometimes in low level design interviews the expectation can also become that you code a certain part of the entire product it can be a small feature itself that you may be asked to code and that can happen in a low level design interview however in a high level design interview uh things are a bit different here you have to imagine what different components will be there how different components that are present in your you know complete system will be interacting with each other what different kinds of other technologies that you will be using what different types of databases you will be using and why you will be using those combination of databases for what purposes so you need to discuss more around the trade-offs that you will be taking uh if you use an rd rdbms what you are prioritizing over at the other how you will be maintaining the availability and consistency of the system if it is at all required or not you will be tasked to identify the functional requirements as well as the non-functional requirements for a particular system and then correspondingly come up with your recommendations and create per se a blog diagram of different you know uh components that will be present what all things that will be present with those components in order to serve the purpose that is required there right so does your system design depend on the type of technology stack that you're using i mean there are a lot of approaches to doing the same thing right so does that thing alter the system design it shouldn't uh so what i uh typically say is that technology stack a person should not be defined by a technology style for example you might be a java developer you might be a c plus plus developer python developer or on stack or any other xyz technology you are working on doesn't really matter uh what i personally believe and feel is that the underlying technology that is being used that will be determined by the product uh or the system that you are designing and not the other way around so you should not have a technology in your mind and then correspondingly try to fit your system into it rather than uh think uh of a system from a holistic standpoint and then come up with uh maybe the tech stack that you will be using the type of database that you will be using and what will better fit your use case so it should ideally be the other way round and uh more often than not high level designs are language agnostic because there you are mostly concerned with you know high level segregation of services uh what all services should be present uh together what all services should be present in a different uh component all together how you will be you know uh decreasing the latency how you will be serving more uh traffic how you will be scaling up and so on and so forth so most of the time they are these concepts are uh language agnostic or text diagnostic so uh that shouldn't be a concern per se right so if you if you were to give an example of a system design we have a question in the audience about it too so how would you you know like design a basic traffic control system that would be the most efficient as for you uh do you want me to design the traffic control system just a basic idea there was there were a lot of questions regarding how would you design something like that so just a basic idea yeah so uh i'll i'll i'll give you an example where this question will be asked or which part of system design is typically expected when someone asks you to design traffic control system right so uh so if someone asks you to design traffic control system or maybe you know a parking lot for that matter or an elevator control system or any of such systems right the expectation generally is not from a high level design point of view the expectation mainly is from a low level design point of view so you need to understand what different entities are present in let's say a traffic control system there will be lights there will be a switching logic that will be present uh which will be doing that actual you know switching of that then there will be an operator that will be responsible for certain things where if let's say a traffic signal goes down what will happen then so you need to identify these requirements first and foremost the basic of system design be it high level or low level you need to identify the base set of requirements that are that you your system will be performing let's see your system will be you know changing traffic lights the traffic lights will be changed according to a set pattern whatever that pattern is correspondingly there will be a person if for example a set of traffic lights go down what will happen in that case there will be a person who will be required to you know maybe uh use a backup light and so on and so forth so you have to first and foremost identify the set of requirements that are present and once you have identified a set of requirements then i always suggest that c what are the high level entities that are present in your system by entities you can easily identify entities with nouns for example whatever nouns are present in your system they will loosely represent entities that are present in the system once you have identified those entities out of the requirement that you have created then you start with the relationships between these entities like how a traffic light will behave when a traffic light will behave in a certain way uh what will happen in other scenarios and so on and so forth you identify the relationships between these entities and then come up with the corresponding class diagrams uh how the classes will interact with each other and the entire system in general right so i'm sure that answers a lot of you know like design related questions i mean that was a really good example of how the things work so uh are there any specific uh questions or concepts where students generally make mistakes in an interview uh yes these are something that i have like always seen is that uh many a times students do not clarify questions and do not come up with requirements because from a system design perspective as well right these interviews are generally quite ambiguous in nature the questions itself are quite ambiguous in nature because the idea is to test whether or not the person or the candidate is actually asking the right questions and trying to figure out what all requirements be it functional non-functional should be there for the system that is present here right so uh one thing that i have seen people is that they do not like ask uh the right questions and you know mainly assume things so one thing that you should never do is like assume uh things in any interview if you have a question if you are assuming something always say it out loud that hey i am assuming these things here and is my assumption correct uh because many a times i've seen people assume things and then halfway through the interview they understand that the assumption was completely wrong and they have ended up you know creating a wrong system altogether that was not a required person second most important thing here is that whenever you are do maybe you know in a system design interview always always ask what is the expected outcome of that particular interview because uh many a times i have seen it it might be a problem from an interviewer's standpoint as well that they have not clarified the outcome it can happen uh not everyone you know has the same interview right so many times i have seen that uh people or who basically you know give these interviews the candidates do not ask what is the expected outcome of the interview and are confused whether or not to create a low level design create a high level design what kind of output you want do you want a db design or not they are confused completely and they you know come up with some design which is not according to the expectation of the interview so always clarify what is the expected outcome of this particular for example when i was interviewing for hd2 roles i always straight up the pattern system design interviews ask like hey can you please tell me what is the expected outcome after 45 minutes what what do you want to see in the screen do you want to see basically the components and its segregation and how i scale up do you want to see the api designs do you want to see the db designs or what is it that you want to see and then you know the candidate or the interviewer used to tell me are these these things is something that i am expecting you will be doing out of this particular interview so always always always ask for the expected outcome from that particular interview and treat the system design interviews as conversations because see interviewers out there they do not want to reject as simple as that whosoever is the interviewer from any company uh to be honest uh whenever they are interviewing they would always like to uh get the candidate working with the particular company right because interviewing is a very expensive process uh and it requires a lot of time so no interviewer out there most of the times i'm not telling there's no bad interview or a good interval it's not like that there can be bad cases as well but most of the times no interviewer out there will want to lose out on a candidate just for the sake of it right so always they will want you to succeed so take that uh for your advantage and have a conversation with them system design interviews are more around how effectively you can communicate with your interviewers and understand and bounce off you know ideas and come up with us design together so that is something that uh you should also always do uh in these interviews which i see students or even you know uh professionals make uh similar mistakes in an interview right so uh i myself am working on an app and i was really worried about you know i was concerned if i should increase the quantity of services that my app is offering or the quality of service i mean obviously the quality of service matters but once you're pitching your idea i mean more the the more services you have the more your idea becomes you know like very attractive so what do you think should be a approach like should we focus on the number of services that we offer or how many services like how can we improve those services so my question to you would be pitching your idea where so where would you pitch your idea like what's the purpose behind pictures okay hackathon for uh maybe a competition or something like that right okay so it might be a bit controversial but yes for a hackathon purposes i would say uh increase the number of services because more the services more attractive your app becomes more attractive your app becomes better are your chances to succeed in the said competition or hackathon or whatever it is right uh but from a real life perspective let's say you have succeeded in that hackathon and you know somehow you have attracted uh some you know interest from top talent or maybe you know vcs that are around there and they want to maybe you know go ahead with your idea for example it can happen uh and if it does happen then i would suggest that from a real life perspective whenever you are building an application to be used by public always focus on quality over uh the number of services that you can push out because yes number of services is good yes people will download your app if you can provide you know let's say 100 200 services whatever it is whatever is the quantum quantum doesn't matter if you provide that people will download it but then if this quality of the services are not good people will not continue with it so there's no point in uh even getting 1000 downloads but if you are not able to convert those people then there is not a viable business model there right so in order to have a viable business model and a good product you need to focus prioritize quality over quantity but yes it's not a blanket decision that you make there are always you know uh trade-offs as i was saying uh not always you will prioritize quality always or not always you will prioritize quantity so in amazon there is a leadership principle which is known as bias for action which essentially means that you should a leader should be cognitive enough to understand when and how much action is required at a given point in time and correspondingly take that up for example not always prioritizing quality over quantity will give you a positive result and not always prioritizing only quantity over quality will give you positive results there has to be a you know balance between the two that you will slowly get to know once you start working properly in that particular domain right so thank you for answering that i mean i was really confused about this but now i think i have something on that thought so what do you think should be the right approach to solving a system designs problem and what is that the person should follow ideally ah yeah so again there is no right and wrong approach per se uh but uh loosely speaking right uh whenever uh one is or let's say you know given a system design problem and i am speaking from a high level design perspective as of now uh in this particular answer right whenever you are given a system design problem first and foremost as i said uh ask for the expected outcome that is required by this particular process whatever is the expected outcome you ask like how will you judge me and what you what are your expectations once that is clear write it down on the screen second write uh both the requirements be it functional and non-functional what do i mean by functional requirements functional requirements are basically what your application or the product that you are designing is supposed to function like what all things it what all services and what all uh features that particular product should have so these are the functional requirements then write the non-functional requirements what are non-functional requirements or mfs they are basically uh they are not the features but what other attributes uh should you consider while designing your system for example certain systems uh you know the interviewer might say that we will prefer consistency over anything else like the system should never went out wrong data for example if you take uh youtube right uh sometimes when you refresh the view count changes view current because becomes less you come view count becomes more or the number of likes become less number of likes become more or in fact in linkedin as well uh the number of followers upon refreshing your profile page sometimes you know the flow follower keeps on fluctuating increasing decreasing increasing decreasing that is because it's not there is some glitch in let's say youtube or linkedin it's mainly because the systems that they have designed they have de-prioritized consistency over availability which which which essentially means that they are okay to went out wrong information for some some amount of time as long as eventually all the systems all the servers that are present which are powering these uh websites or powering these services they will become consistent so they see that it's it's not a deal breaker if let's say you know as a content creator instead of let's say 10 000 views you are seeing 9000 views it's fine as long as two days later uh all the servers you know reconcile their data and you get to see 10 000 or 11 000 use whatever is the actual number of views that is present so uh these are uh the non-functional requirements that what your product that you are building should prioritize or should it prioritize consistency overall should it um should it prioritize availability overall should it be uh near real time so these non-functional requirements will determine how you build your entire system do you build the system as a synchronous system where you know the user will put in an input and then is expected to wait till he or she gets an output or it's an asynchronous system where the user you know puts some input and is uh and forgets about it which means as long as i have put the put any information in the system i know that it will succeed when it will succeed i don't know that sometime in the future it will succeed but i don't know when it will succeed but as soon as i have entered all the required information there it will succeed at some time in the future it doesn't really matter so all these informations will then correspondingly uh basically you know correlate to what different technologies what different services you will be using would you be using uh let's say a message broker uh for a synchronous event processing will you be using something else what kind of database you will be using uh will you be using a mixture of databases for different kinds of you know uh information that you are storing maybe you need transactional database for some you know payment related information that you want to store or process uh maybe you require something else altogether so all these decisions will then correlate to uh what kind of components he will be using and then correspondingly once you have these requirements written then start with first and foremost estimation because that is extremely important even for example when i am building systems in my own company as well the first thing that we do is estimate what is the expected traffic that our product is supposed to get and correspondingly in future let's say three or four years down the line three or five years down the line what is the expected growth in that traffic that our system is supposed to get because on the basis of this number what you will be using in the system will completely change for example if the expected traffic is not high for example let's say it's less than 1000 uh transactions per second for for that matter right uh then you might be better off not using a server for that matter and build your system in a server-less architecture for that matter it can happen i'm not saying it will always fit your use case it all depends upon the use case as well but it can happen so the amount of you know traffic that you will be generating the amount of data that you will be generating that will correlate to what kind of systems you will make so always make back of the envelope calculations for the expected traffic and then correspondingly slowly and steadily come up with you know the basic components that can be present how the components will communicate with each other which they communicate through simple rest apis will it be a publisher subscriber kind of a mechanism and so on and so forth so these are now you have to become a lot more creative in solving the problems and yes that's how you slowly and study having these discussions with the interviewer come up with a basic you know structure of the product right so i have another personal question what is the amount of coding that is involved in a system design job so uh system design job per se is not a separate job uh as a software development engineer you are expected to design systems so designing systems is more around understanding uh what the system needs to do how the system needs to do what all constraints you have do you have constraints on let's say uh the cost of the system because uh see one thing is that if you throw money you can build anything for that matter but do you want to throw money that much amount of money to build something that can be done way cheaper obviously you would want to find ways in which you can you know uh create the same product with the same latencies with the same you know capabilities at a much at a fraction of cost for example the example that i was talking about right uh where i was talking about you can maybe think about using a server or maybe you think about completely doing serverless so uh taking that example i don't know maybe maybe it might go tangent to many of the folks that are present who has not for save work directly on serverless architectures but any which ways uh talking about that uh what i wanted to say is that serverless architectures for uh for systems which do not have you know high load they do not cost a penny for example i'm not even saying it it costs literally zero dollars uh because of you know uh around you know it depends upon what kind of cloud you are using but many of them you know do not charge you money for around one million requests per month if your system is getting just one million requests per month it will not charge you any money at all so so that much amount of difference that can happen and in case of a server it can it can go huge because servers are uh typically you know rented by the hour so obviously you want your system to be available every time so your servers will be over on every time and if your server is on every time it will be charged a set amount of money for sure so it can have a huge amount of difference at the end of the day depending upon what kind of architecture you are building so uh it's about understanding what different uh options are available what different you know tools are available to build this particular architecture for example message broker that i was talking about for you know asynchronous event processing there can be different kinds of message brokers or messaging queues that are available for example there is active mq rabbit mq apache kafka there is sqs and so on and so forth now you need to understand your use case and then evaluate between these uh to see which one fits the bill perfectly and then correspondingly come up with the design so from system design per se there is no coding but to create the set design you there is a lot of reading there is a lot of understanding of what different tools are available to build certain things a lot of resign research goes into it to create a particular design per se low level design yes there can be but again coding per se is not required understanding of object-related principles design patterns is required for coming up with a low-level design there right so this is one the question i'm about to ask is one of the i think most important questions that needs to be answered by an expert such as yourself so what are the best resources to follow for system design and how much time should a beginner devote to it so uh from a beginner perspective right uh i do not expect uh as the one or a beginner to be proficient in system design per se because they are not exposed to set systems right obviously when you are working in a college or when you are building your personal projects you are not at all exposed to uh let's say the level of scale uh that or a production system can get like you are not exposed to hundreds of thousands of you know requests coming in per second for that matter so so the expectation is not there really uh from a fresher uh to be very proficient in system design but as you grow in your career system design will become uh very very pivotal and those of you who will become better at system design will definitely be able to grow much faster in your career in comparison to those who will not so from system design i would say start reading you know blogs that are available every leading company uh have the engineering blogs where they you know constantly post information about how they are solving certain challenges what kind of challenges they are getting how they are migrating from let's say rdbms to a nosql database or vice versa for that matter and why they are doing it so start reading those like netflix has a very good engineering blog facebook obviously has a very good engineering blog or amazon has uh the aws for example has an amazing engineering blog like one of the best i have seen then uber has hazard all the major tech firms have their engineering sites snapchat and so on and so forth and there they uh discuss about all of the technological challenges that they are getting and how they are solving to start by reading that even if even if you do not understand let's say anything for that matter what you will know you will know about certain terms right at the at the very least you will get to know about certain terms that are being used there take up those terms search it in the net and then keep on reading about it it's a it's a long process it's a continuous process that you need to do in order to better yourself and it's it's it's full of you know doing research and development around the things that you are reading uh in fact swiggy for that matter i am only talking about you know international embassies swiggy has a very good engineering block and to be honest uh i was reading up how they calculate their epa uh when you let's say order something from swaggy rate uh you get like your order will be delivered in let's say 23 minutes or xyz whatever it's how they calculate their eta and why they cannot rely on google maps for edm it's a very interesting read to be honest and they have created their own propriety algorithm to calculate the atn they do not use google maps because of certain reasons that has been very very clearly explained in that block so read them like that's the best way one can become better in system design and then correspondingly there are some three blogs that are available uh like high scalability block is one block that is like amazing uh from a system design perspective uh you can read them uh then there is a book that is available uh which is i think so designing data intensive application ddi uh you can search designing data intensive application that is like you can consider that as a you know bible for system design so you can definitely read it but yes there is no shortcut or no other way around here it's just you have to keep on reading it and understanding the constraints at this point every tech expert i talk to they're all about read blogs read books because that's the that's the you know like that's the food that will give your knowledge some power to grow so i have this one last question and if there are any other questions in the chat then we'll take them up so is systems design asked in sde one level interviews so typically speaking no but there are certain companies that do ask for example i think so i have seen atlassian ask system design questions to sd1 i've seen linkedin ask system design questions to as demon but for most use cases right always prepare for the most rather than preparing for exceptions because then you it will just overwhelm you as simple as that uh prepare for 90 95 of the use cases you should be fine there are like hundreds of good companies that are out there that are paying good money and you can get jobs there without having you know good uh stronghold of system design uh mostly no i would say sd1 interviews will not comprise of you know high level design per se but depending upon your experience it see sd1 is not only freshers right or even one year two year three years of experience people can come in as d1 right and depending upon that experience uh it might so happen that certain companies do ask you low level design questions that can happen for example when i used to go uh interviewing for a cesium de sho for that matter right uh i i i have asked uh object-oriented design type questions to even interns there as well so it all depends from one company to another uh you might be asked low level design questions yes but high level design questions for most use cases you will not be asked but as an sd1 in order to grow into sd2 right one of the basic requirement for any company is that the particular sd1 needs to be proficient in designing systems because as an sd2 right from day one whenever you join a company that's the basic uh ask that a company has that you will start contributing into designing systems right from day one and i'm not at all kidding i'm not saying that uh just for the sake of saying but it's it's really the expectation out there for an sd too so in order to get promoted as well the expectation is similar that you will be taking on design challenges you will be taking on such you know set design and coding challenges in order to uh in order to you know get promoted to the next level and so on and so forth so uh even though it might not be directly asked per se uh in interviews but in your day to day job if you do not take uh a take up system design you will not be able to get promoted to the next level and uh for that you have to read right so i guess that's it for the questions that i have thank you so much amajit for such an informative session and for answering all the questions uh for those of you watching us you can all connect with swamiji on his linkedin and you can also connect subscribe to his youtube channel for any further updates that he can provide and thank you all so much for joining us and if you wish to be a part of other sessions and avail the benefits of gsc 2022 then you can check the links in description and just a heads up only a few days are left so have a great day everyone thank you so much once more and have a great day thank you so much it was a blast interacting with you thank you so much means a lot bye take care bye youtube