Fundamentals of a System Design Interview

System design (also known as Technical Architect questions ) is a standard part of the software engineering interview process in any technology company. This page will provide you with a System design 101 or as some call it, a System Architect Interview. Most of the top tech companies have highly complex, micro-service-based systems and so, in order to work there, they expect candidates to be aware of some basic distributed system architecture & system design. They expect them to perform well in these interviews. Your good performance here will get you the upper hand in negotiating the position and salary from the interviewing company. Having said that, it is a well known fact that, Most engineers struggle with the system design interview. This is because of two reasons: either they have a lack of experience in developing large-scale systems OR, and more importantly, even with experience, the nature of their response is not “structured” and “well thought through”.
And, there lies the key, these problems are vague and open-ended by definition, you need a framework and mental model to solve them right. (Shameless plus, this 9 step model and framework is exactly what we at the stackInterview have mastered, and can help practice).

Step 1: is always to clarify the requirements and seek answers to disambiguate the problem statement. There is no one right answer, and therefore the better job you do at the first step, the higher your chances of building something which the interviewer has in mind! For example: ‘Design Facebook’ is a pretty vague question but bounding and scoping the problem set is a vital piece of the puzzle. In this case, for example, ruling out push notifications, and multimedia content will allow you to focus on other pieces better.

The output of step 1 is a well-bounded and scoped problem statement and a starter list of functional requirements.

Step 2: is to write down the concise problem statement and confirm the bounded scope. In our experience with training candidates, 10% or fewer do this step, and that 10% have 30-40% higher chance of succeeding than the rest.

The output of step 2 is a confirmation from the interviewer that what you are about to solve, is what they want to see you solve – and not what ‘you think, you should solve.

Step 3: is to write down the non-functional requirements. We will explain them separately in a different article but in short, Pick any two from Consistency, Availability & Partition tolerance. Then pick reliability and Latency.

The output of this step (Step 3) is a written list of non-functional requirements; we will use these to make the right trade off’s throughout the problem.

Step 4: is to do a basic capacity estimation, concentrate on three things, how much storage will we need. How much network bandwidth are we going use, and what the QPS of the system is going to be? The capacity calculations will help with deciding the scale tradeoffs.

The output of this step (Step 4) is a good estimation of scale and using that we will be able to build the micro-services we need, and the kind of components we choose, e.g. SQL / No-SQL or Long polling versus web sockets.

Step 5: is to write down & define the data model. E.g. when designing Twitter, how would you define the data model for a users’ tweet? What all data models does your app need?

The output of this step is a written list of objects and their models, visualize a good old SQL table one table per model.

Step 6: is to write down & define the API’s your app is going to have. E.g. when designing Twitter, how would you define the data model for a users’ tweet? What all data models does your app need?

Output of this step is a list of core API’s. Don’t implement them ! Just the input & output parameters. E.g. retCode sendTweet(api_dev_key, sendingUser, tweetContent, contentType, parentTweet // null if not a reply or RT) etc.

Step 7 is a high-level design – This is where you draw the top blocks for the end-to-end system that you would like to see. What different microservices would you like to have? Which ones are stateless/stateful? Which ones talk to the DB? Which ones are backed by cache? Why?

The output of this step is a block diagram of your system with all services labeled and at the bare minimum having clients, load balancers, application servers, File storage / DB’s.

Step 8 is a detailed design walk-through– This is where you establish connections between the services, and establish how they connect, to whom and for what. How do the stateful ones keep state? How do they talk to the DB? Should they?

The output of this step is an end-to-end walk-through of the system for the greenfield case.

Step 9 is a bottleneck analysis, and a final walk-through of all functional requirements to make sure that nothing was a miss. Imagine designing Uber and realizing that you missed the scenario to cancel the ride.

The last and final step is a check with the interviewer! If you are interviewing soon with a company and would like to practice this live, hit us up using this link, and we will make sure you get the practice you need at the time you need it. Thanks & Good Luck!