Asking questions in an interview is a great way for the interviewer to gauge your skill level, knowledge, and determination. It is important to ask a few vital questions that make the interviewer go, “Hey, this person actually knows their stuff.” And this is especially the case in any High Level System Design round, with a specific focus on questions that cover aspects of the entire system.
This purpose of this extensive cheat sheet that we’ve created is so that during your interview for a High-Level System Design, you are the person in the driving seat and can showcase your expertise, to crack interviews at big tech companies like Microsoft, Amazon, Uber, Atlassian and more. In this extensive list, you’ll find that some questions are not so relevant for certain systems and some other questions are, but it will make sure that you don’t miss out on any aspect of the system. Let’s get started!
Who is the Customer?
The most important aspect whenever you are designing a system is to understand who the customers are. For example, when creating, let’s say, an Uber-like app, the first and foremost thing to understand is whether this app is for the driver or the customer. Similarly in a food delivery app, should you be designing the app for the restaurants who deliver food or the person who orders food?
So it is one of the first and most critical questions to put forward and to clearly understand.
What is the Module to Consider?
All systems are made up from a number of different modules and components. You will need to understand which module of the system the interviewer wants you to focus on and design. Consider a food delivery app, which has two modules. The first module deals with the restaurant recommendation system and the second module deals with the geolocation, tracking and delivery aspect of the app. Being clear with which module you would have to design from the start of the interview helps bring a lot of structure to your interview.
What is the Scale of the System?
Knowing the scale of the system helps a great deal in wisely making several decisions that you would have to make in the future. Later in the interview, you may be required to make decisions such as which database to use etc. and knowing how many users you expect to use the app helps greatly in determining what is better. In this part, you can also ask what the scope of the system is, whether it is for within India or across the globe, so you can model your decisions accordingly – like determining whether you will use CDN or not.
Consistency vs Availability
If you’re familiar with the CAP theorem, then you may know that if you’re supporting partition tolerance, you can then only give preference to one of the two – consistence or availability. For some systems, it is clear from the get-go that it should prefer availability over consistency, and vice versa. For example, systems dealing with any sort of currency, consistency is of the utmost importance. Although you may deduce what you should prefer for the system, it is better to discuss with the interviewer and clear up any misunderstanding. It will be very impressive to the interviewer that you are thinking of these aspects from the start and making your decisions based on these earlier responses.
What is the Sequence of Events?
By understanding the responses to all the questions we have asked so far, we can make informed decisions for our next step. The next thing to think of is the sequence of events. For example, in a food delivery app, the sequence of events might go as follows:
View list of restaurants -> Potentially filter the list based on geolocation -> Select specific food items -> Add to cart -> Perform payment processing -> Delivery personnel is assigned -> Food is prepared and delivered.
While discussing the overall sequence of events of the app, your main focus should be on the main module that you would be dealing with, and deep dive into the events that are going to be happening in that particular module. If you were to design the delivery part of the food delivery app, you would focus on the sequence of events surrounding delivery:
- When will the delivery personnel be assigned?
- How are they going to be chosen?
- When does the food start to be prepared?
- When will the food be marked as Delivered?
What are the APIs?
API design is an extremely significant part of the interview. After figuring out the exact sequence of events that are going to happen in the system, you can discuss the APIs that you will have to design, and for some interviewers this is a very crucial step. They expect you to design these APIs in comprehensive detail – writing the exact requests that are going to be sent, their exact responses, who sends the request and who fulfils it. Thus, it is important to work out the ins and outs of the APIs.
Microservices
After finding out exactly which APIs you must design, the next step is to discuss the micro services which will be present, and how the different responsibilities will be handled by the different micro-services. Being a bit more precise, you can draw out what microservices will be needed, what exactly will be happening in those microservices and how these microservices will be communicating amongst themselves.
Mode of Communication
The mode of communication must always be decided beforehand. In some cases, like when data has to be sent from a client to the server, it’s pretty simple, we simply use http or https in that case. But for when data has to be sent to be sent from server to client, there are a number of different ways to do so, like web sockets etc. Now would be the best time to discuss them with your interviewer. Keep in mind, the interviewers focus on the server to client communication, as that is the tricky part potentially involving web sockets.
What Data is Needed
Knowing all the aspects we have discussed in the above points; the next part is to know what exact data is going to be needed in your system.
Data Flow
Once you find out what type of data you will be dealing with, you should talk and discuss about the data flow, what components and microservices will be aware of what data and have access to it.
Kinds of Data Store
Determining how the data will be stored and which kind of database will be used – SQL, NoSQL, etc. – is the next step. You will have to deduce which database is best based on the conditions, and you will most likely have to justify and explain why you used that particular database. Considering you are aware of all the aspects that we have discussed above, it should be fairly simple to come to a conclusion. For instance, if you’ve already discussed consistency vs availability, you already know whether you’re going to optimize for read or write.
Scaling of DB
Once you’ve done that, you should discuss how you are going to scale – through Vertical scaling or Horizontal scaling. You should discuss and work out a solution to how you are going to serve the capacity that you are estimating.
Caching & Sharding
Since most systems deal with a bunch of data, you must take into account how you would deal with them. Caching and Sharding are really helpful for managing data. You can talk about CDN, and further decide how the databases are to be spread across the globe and how they would be shared. Like, for India, there would be a separate database and for US based customers, a separate database.
There can be some further questioning in this regard, for example, a US customer wants to order food in India. What then? So, you need to keep such aspects in mind.
Sharding is also an important consideration. For example, if we are dealing with a SQL database, it is extremely difficult to scale it. You can shard it based on a unique ID, but of course, it all depends on the system. Consistent hashing will also come into play when implementing sharding within your system.
Failure & Fault Tolerance
Resiliency is yet another important aspect of your system that you need to discuss with your interviewer – failures and faults, and how you deal with them. If one of the microservices or databases fail, how do we recover from it? You must think of a methodology which is to be used for resiliency, whether you are to use Master-Slave architecture or Peer-to-Peer, you have to consider this possibility and make sure that no data is lost. Whether the system is more consistent, or will it provide more availability, all factors must be discussed and cleared up.
The next few points are usually ignored by a lot of people, but some interviewers do give a lot of importance to them, so it’s better to mention or briefly discuss them with the interviewer.
Health Checks
Health checks are an essential part in any real system. By sending a heartbeat or through another mechanism, checking on whether all your microservices and database stores are running properly is very important to make sure that the system functions appropriately.
Logging & Monitoring
Another aspect that most interviewers might ignore, but can pop up unexpectedly is Logging and Monitoring, where you find out what component caused the system to fail. So it’s better to shortly discuss and create a separate logging and monitoring service, how the data is to be communicated to the service, and how it will be stored or analyzed.
Security
Communicating over the network, using HTTP or HTTPS, comes with their overheads, but makes the mode of communication secure. However, when two microservices are to communicate amongst themselves, it may not need to be super secure. If the communication does not contain any sensitive data, using HTTP or HTTPS may be unnecessarily bad for performance, so you must decide when to use HTTPS and when not to.
Algorithms and Data Structures
Although most people consider that a question could never arise from data structures or algorithms, some interviewers might discuss an algorithm or a data structure that may be being used within a component of the system. For example, in a food delivery app, when discussing the geolocation and delivery aspect of the app, the interviewer may ask about the algorithm being used to determine the quickest route for the delivery. So, you must keep in mind that such aspects could be talked about in detail, and you should be prepared.
This is a tried-and-tested list of questions that have worked for us in High Level System Design interviews, and we hope this helps you drive your own interviews in a structured manner that helps showcase your knowledge and capabilities!
Would you like to watch a video walking you through the different questions in our HLD cheatsheet? Check out our video on the official YouTube channel!
