In a system design interview, you are usually given a real-world product and are asked to design that product. For example, you could be asked to design Twitter as a part of system design interview. Mostly the round is focused on High Level Design, but some interviewers may even decide to go into the Low-level design of some component.
Unlike the coding round, there is no absolute right or wrong answer in case of a design interview.
As a part of system design interview, you will be judged on the following aspects:
- Scalability: What is the scalability of your system and what are the scaling bottlenecks. If we need to increase the throughput of the system (past the current scaling limit), then can we increase it incrementally? Whether your system is horizontally or vertically scalable.
- Resiliency: How resilient is your system. Under what circumstances it can fail? What will be its down time if it fails? Does it have any single point of failures?
- Tradeoffs: Do you know and understand about the tradeoffs that you have done as a part of developing your system?
- Communication: How well are you able to communicate your design choices, articulate your thoughts and how well can you answer the counter questions that get raised during the design interview.
System Design Checklist
While working on the design problem, make sure you keep the following points in mind:
- Clarify the requirements: Most of the times, we are given a widely used product to design. If that is the case, many times people make the mistake of not clarifying the requirements, since they have already used the product themselves. Instead, even if you have used the product yourself, you should clarify each requirement down to bare minimum and only then start the design process.
- Divide into subcomponents: Make sure that you divide the whole system into independent subcomponents and clarify whether you are supposed to design the whole system or a subcomponent for system. It is up to the interviewer, whether he wants a deep dive into one subcomponent or whether he wants to have an overall picture of the product.
- Understand the scale: For each subcomponent, get a rough estimate of how much load would that component be handling and only then start designing. For example, when designing Instagram, think about what is the max image size that you will be handling and how many image uploads can you handle in a second.
- Database: Think about the database that you will be using. Whether it will be better to use a NoSQL based solution or a relational database and why? Think about whether the choice of database would make certain use cases easy or difficult to handle in future? Will your database be able to support the throughput required? How will you scale your database, if the expected throughput increases?
- Communication: How do the different components of the system communicate with each other. Do they communicate synchronously or asynchronously? What is the impact of this communication on resiliency and latency?