System design interview

In this video, we talk about the system designinterview framework that we use in the books.We explain why you may want toconsider using something similar when you interview.Now, let's first talk about why wemay want to follow a framework.Interviews are stressful.There's very little time to showoff what we are capable of.Without any structure, it is easy to wasteprecious time on things that don't matter.An unstructured interview makes it difficultfor our interviewer to follow.Our framework provides a time tested structure.It is simple and powerful.It leads us to ask the rightquestion and focus on the right things.Here are the four steps of our framework.Step one understand the problemand establish design scope.Step two propose high level design and get buy in.Step three design deep dive.And step four is wrap up.This framework works well for a typical 45to 16 minutes long system design interview session.Usually the first five minutes is an introductionand the last five is Q and A.The meat of the interview isonly about 35 to 45 minutes.We suggest allocating about five minutes to step120, minutes to step 215, minutes to stepthree, and five minutes to step four.Now keep in mind this is just a rough guideline.Feel free to adjust as needed.Let's take a closer look at each of the four steps.Step one understand the problemand establish design scope.System design questions are usually open ended.Sometimes they are presented in away that is deliberately vague.This tests our ability to organize ourthoughts and focus on what is important.It is our job to ask as manyquestions as necessary to understand the problem fully.It is a red flag to jump right intoa solution without first understanding what we are building.What questions should we ask?Our goal is to clarify the requirements.We want to understand why we are building the system, whothe users are, and what features we need to build.For example, if we are asked to design a chatapp, it is important to recognize that there are manydifferent types of chat app in the marketplace.There are one on one and small groupchat apps like WhatsApp office chat apps likeSlack or group chat apps like Discord.They have different design challenges and constraints.The goal is to understand the featureswe are building in priority order.We should focus on the top few features to build.Make sure the interviewer agrees to the feature list.It is also important to ask aseries of questions to clarify the nonfunctionalrequirements for system design interviews, we suggestfocusing on scale and performance.These nonfunctional requirements are what makeour design unique and challenging.For example, designing a Twitter clone to support afew hundred users is easy, while designing it forhundreds of millions of users with some popular accounts,having millions of followers is interesting and challenging.Now, the more senior the role is, themore important it is for us to demonstrateour ability to handle the nonfunctional requirements.Now, to help us get a sense of the scaleof the system and the potential challenges and bottlenecks, wemight do some rough back of the envelope calculations here.Keep in mind that and the potential challenging sothe map we do here is a rough estimate.The goal is to get a general sense of the scale.We want to get the order of the magnitude.Right now, this step should take about five minutes.At the end, we should have a shortlist of features to design for, along witha few important non functional requirements to satisfy.For step two of our framework, we aimto develop a high level design and reachan agreement with the interviewer on the design.For most designs, we would suggest atopdown approach and start with the APIs.The APIs established a contract between theend users and the backend systems.It should be clear after gathering therequirements what APIs we would need.Unless it is specified otherwise, we shouldfollow the restful convention, define each Api'sinput parameters and output responses carefully.Take the time to carefully review the APIs,verify that they satisfy the functional requirements.Equally important to remember, do not introduce APIs thathave nothing to do with the functional requirements.An additional consideration on API some designs may callfor two way communication between client and server.Now, in this scenario, Websocketis a common solution here.Be mindful that a socket servicelike Websocket is usually stiff.It is quite challenging to operateat scale if scale is high.Be prepared to discuss how we would managea Websocket deployment in the Deep Dive section.Once we have established the APIs between theclient and the server, the next step isto lay out the highlevel design diagram.The diagram is the blueprint of the overalldesign that we can refer back to.We should use it to verify that the designsatisfies all the feature requirements end to end.For many designs, you start with aload balancer or an API gateway.Behind that are the services thatwill satisfy the feature requirements weestablished earlier with the interviewer.Many services require some form of persistence.This is where we would rank out thedesign by introducing the data storage layer.It is usually not necessary to specify theexact database technology to use at this stage.This should be deferred to the DeepDive section if necessary, and only afterwe have designed the data schema.For example, for a map service likeGoogle Maps, the client often needs tosend frequent GPS updates to the server.We include in a design a location data storethat a location update service would write to repeatthe steps above and complete the high level designdiagram for all the major features.Here's a pro tip whiledeveloping the high level design.Maintain a list of discussion points for later.Resist the temptations to dig intotoo much detail too early.Do not dig ourselves into a hole beforewe have a full picture of the design.The last step of the highlevel design isto hash out the data model and schema.Here we should discuss the data accesspatterns and the read write ratio.At scale, data modeling could significantlyimpact the performance of the design.It is simple.Also discuss the databases to chooseand maybe discuss the indexing options.Here we should make some judgment calls.If the data modeling is the key part of thedesign to satisfy the nonfunctional requirements, we might want todefer the discussion to the deep dive section.When we are done with the high level design,take a step back and review the design.Make sure each feature is complete end to end.Here we reach the third stepof the framework design deep dive.The goal of this section is to demonstrate thatwe could identify areas that could potentially be problematicand come up with solutions and discuss trade offs.We should work with the interviewerclosely to decide what to discuss.In depth deep dive is where nonfunctional requirements make the problem interesting.The higher the level, themore important this section is.The section is really open ended.There is no one size fits all approach.Here is where the ability to read the room is useful.Sometimes the interviewers body language will giveaway clues that they are dissatisfied withcertain aspects of the design.It is important to pick up these cluesand make sure the issues are addressed.One way we could approach it is by asking questions.We could list out the reasons forchoosing a particular solution and ask ifthey have any questions or concerns.Once we pick out a problem or twoto dive deeper into, we should come upwith multiple solutions and discuss trade offs.For each option, we could use thefollowing mini guidelines when framing the discussions.First, we should clearly articulate the problem.For example, for designing Google Maps, the rightQPS at 1 million location database is toohigh for a single database to handle.Next, we come up with at least two solutions.Continuing with the example above, we could propose toreduce the location update frequency per user or choosea NoSQL database that could handle the right rate.Third, we discuss the trade offs of the solutions.Remember to use numbers to back up our design.Finally, we pick a solution anddiscuss it with the interviewer.Now repeat this for other problems.In a typical interview, we should only have time todive deeper into the top two or three issues.Lastly, we have reached the last step wrap up.We suggest spending a fewminutes summarizing the design.Here, we should focus on the partsthat are unique to the particular situation.Keep this short and sweet.Leave enough room at the end of the interviewto ask the interviewer questions about the company that'sit on the System Design interview framework.We hope you find it useful.If you like our videos, you may likeour Wiggley System Design newsletter as well.It covers topics and trends in largescale system designs trusted by 2000 readers.Subscribe at Blog by Bikeo.com.