8 Most Important Steps To Follow in System Design Round of Interviews

In the software engineering interview process system design round has become a standard part of the interview. If you want to get your dream job in some big tech giant companies (especially as a senior engineer) then you need to tell your approach to building a complex large scalable system. 

There is no accurate and standard answer to the design problems. You may have different conversations with different interviewers for the same question. Due to the lack of experience in building a large-scale system and the open-ended nature of this round a lot of candidates struggle with this round. Not just junior and mid-level developers but also experienced developers feel uncomfortable in this round. 

This round is not much focused on coding. The interviewer wants to know how you architect the entire system and how you glue them together. You need to cover a lot of complex components within the timeframe of 30-45 minutes. Due to the limited timeframe most of the candidates get lost in small things, and they miss out on the big picture. 

In this blog, we are going to share some tips to structure your interview in a way that you become able to convey the whole big picture of your system to the interviewer. Before that, we recommend you to read the blog How to Crack System Design Round in Interviews?

1. Take Ownership and Drive the Interview Process

When the interviewer asks the design question to you, take the responsibility of the owner to drive the interview. Treat your interviewer as a team member and consider this round as an opportunity to work with him. You’re the one who has to lead everything, not the interviewer. But that doesn’t mean you won’t allow your interviewer to speak something. If the interviewer shares something or points out something, listen to them carefully. 

You will be the one doing most of the talking and you will be the one who will explain everything in your design. You need to call the issue proactively and you also need to handle the edge cases if in case the interviewer pokes you on. 

2. Functional and Non-Functional Requirements 

Mention all the functional and non-functional requirements clearly to the interviewer. Your requirement should be big enough that can fit into the given timeframe and makes the problem challenging for you. Once you know the functional and non-functional requirements, build a system that fulfills those requirements. 

In software, development scalability matters a lot so keeping in mind the non-functional requirements, you need to build the system on a large scale. There is no fun in working on a system at low scalability. 

When you clear out the functional and non-functional requirements, review them with the interviewer. It may be possible that they want to add/remove something. Sometimes interviewer wants to add some specific requirements or use cases in the system which you’re going to build. 

3. Capacity Estimation

A lot of candidates skip this part, and they do not consider the system’s capacity. Most of the candidates just focus on the design part and don’t calculate to estimate the capacity of the system. They assume a large enough approximate number for the number of cores required or the amount of space required. You will have to check with the interviewer if they want to get into capacity estimation or not.

4. Plan

Once the functional and non-functional requirements are clear, you need to plan various things to design your system.

• Check out the user interaction point in your system. How the flow is going to work in the entire system when a user interacts with it.
• At each user interaction point, you need to check the latency, availability, and consistency requirement. You may have to make some tradeoffs and that totally depends on the requirement.
• Make a quick analysis and evaluate if your system is read-heavy interaction or write-heavy interaction.
• All the above three points are going to make a few things clear for you in your system. What all services do you need and which database is suitable for your system to store the data?

5. High-Level Design

This is the most important and challenging part of the system design round of interviews. In high-level design, you’ll have to cover the following things.

• The entire system flow should be divided into multiple functional components. Check what all services are present and how you need to build the entire system based on these services. Also, check if the requirements or the services fit into the microservice architecture or not. Most of the time in SDE interviews candidates prefer to use a microservice-based approach.
• Check how the services are connected in the system and which protocol is good to use for the communication of internal services such as Async/Sync- Rest, RPC, etc.
• You need to make it clear to the interviewer what all services are available to the users and how users are going to interact with the whole system to use these services. How a complete flow of the services will be working in the entire system? Do you need the cache to reduce latencies in the system?
• You need to identify which database fits into which of the service in your system.
• Check if you need caching anywhere in your entire system. If yes then what should be the eviction policy and do you need an expiry for the keys? Is it needed to be a write-through cache?
• Based on all the above analyses, draw a high-level design of your entire system.

Key Things to Have in HLD

• Load balancers to distribute the entire traffic to different servers.
• Services
• Databases and Caches
• User Interaction Points
• Tools like a message queue, CDN, etc.

6. Walkthrough of the Design

When a complete diagram is ready, walk through your entire design. Take one component/one use case of your system and explain to the interviewer at a high level how this component is going to work in your system. You also need to tell your interviewer which specific database is suitable for your system and why you need to use a specific mode of communication such as Sync/Async etc. 

If you have made a specific design choice in your system, you can get into RPC vs HTTP kind of conversation. You also need to check the data replication strategy (for example Master-Slave or a Multi-Master setup) used in your database. 

Note: When you walk through the design process make sure that you don’t get into the much detail of designing the API or DB schema. You may run out of time and you will miss out on some important things in your system. Get into the detail only if the interviewer asks for it. 

7. Implementation and Execution

When you are done with explaining the design of the entire system and it flows to the interviewer, take a review and ask them which specific part or flow of the system they want to discuss in depth. Due to the limited timeframe, it’s not possible to go over the entire system and explain every part in detail. 

Let the interviewer decide which specific part of the system they want to dig into. As per the interviewer’s choice explain the implementation and execution of that specific component of your system. You need to cover the following thing…

• APIs: Mention which APIs are needed in your system. Also, make sure that you’re using the best practices when you’re explaining the API to your interviewer. For example: If you’re using the URL for GET API then instead of using GET /user/getUserbyUserId, it’s good to use GET /user/{id}. 
• API Protocols: You also need to check the protocols you are exposing the API on. A lot of people choose REST APIs but depending on the use cases/system requirement you can choose something more efficient like Thrift or Protobuf.
• Events: You also need to check the events a specific service is listening to, which of the service generated that event, what payload comes in, and what kind of processing is happening on that event.
• DB Schema: Check out the DB schema in your system. When you’re talking about high-level design, you need to clarify which database is suitable for your system and why did you choose that specific database. Here you need to decide between SQL and NoSQL. 
  If you have chosen SQL then talk about the indices and optimizing the queries. If your choice is NoSQL then make sure that you check the consistency guarantee your DB provides. Is it the cause of any issue and the kind of queries you run on that DB? When you are clear about your database selection and DB schema, call out the keys for the key-value store or the partition keys for a columnar store, etc.

8. Handle Murphy’s Law

Most people skip this part in the interviews but this is one of the most important things you should cover in this round. This part talks about how resilient your system is. Things will break in the real world but when it happens you need to make sure that you’re in full control of your system. 

Discuss how you need to monitor the overall system and how you look at every part of it. Mention the alerting mechanism you have in your system. Discuss the KPIs (Key Performance Indicators) and the way you keep track of them. How would you deal with the problems if things will break if your system goes down if your service crashes if your DB’s master node goes down or if the data centers go down?  

Mastering System Design Course by Geeksforgeeks

Want to get a Software Developer/Engineer job at a leading tech company? or Want to make a smooth transition from SDE I to SDE II or Senior Developer profiles? If yes, then you’re required to dive deep into the System Design world! A decent command over System Design concepts is very much essential, especially for working professionals, to get a much-needed advantage over others during tech interviews.

And that’s why, GeeksforGeeks is providing you with an in-depth interview-centric Mastering System Design Course that will help you prepare for the questions related to System Designs for Google, Amazon, Adobe, Uber, and other product-based companies.