System Design Introduction
System design interviews are used to check your thought process and how well you respond to the uncertain nature of an open-ended question in the given amount of time. So remember you are not expected to provide with a complete solution say in 1 hour but a working solution with limited functionality.
Things to keep in mind while giving system design interview
You need to keep in mind these 3 things while giving a system design interview.
- Don’t get overwhelmed by the problem
- Think before you speak
- Drive the discussion
Distributed Systems & Its 3 Principles
Any system which includes multiple components residing on multiple machines coordinating through some sort of mechanism like sending messages to achieve a common goal is a distributed system.
- Single responsibility principle – Each component present in System Design should have a single job to perform.
- No single point of failure principle – The system should never have any component whose failure will result in the failure of the entire system.
- No bottleneck principle – Since we design for scalability our system should not have performance bottlenecks. Ideally we should horizontally scale our system to handle the large amounts of processing.
5 Step Guide for System Design
This is a 5 step procedure which will help you tackle any system design question.
- Requirement analysis – Here we first discuss the functional requirements i.e. what this system should do. Then we discuss the non-functional requirements i.e. how the system should behave.
- API design – Here we define the interfaces we expose to the outside world using which the communication happens. Here we have to define the name of the apis, the parameters it takes and the return values.
- Define data model – It is a representation of object data, its association between different objects and the rules it should follow.
- High level design – This depicts the required component blocks with arrows showing the data flow. The components can be load balancers, web servers, application servers, databases, caches or custom components performing some action like filtering, reading, processing , etc. The high level design shows how the data flows from an entry point to a database and vice versa.
- Scale the design – This is necessary because today’s systems are generally large scale distributed systems. To process large data we need to add multiple machines since it is difficult or rather impossible for one single machine to do everything. You need to find all the bottlenecks and fix them.
Reader/Writer System Design Solution
Let’s design a simple Reader/Writer system using the 5 step guide.
1. Requirement Analysis
The problem statement is that we have to design a reader/writer system which saves and retrieves employee data.
Functional requirements
- Save the data
- Retrieve the data.
Non-Functional requirements.
- High scalability
- High availability
2. API design
We need the following APIs to save and read employee data. These APIs suffice the basic functional requirements.
- createEmployee(empId, employeeName)
- createDepartment(deptId, deptName)
- addEmployee(empId, deptId)
- Employee getEmployee(empId)
- List
getEmployees(deptId)
3. Define data model
Let us now define the data model. We will have 2 tables Employee and Department. Department table will have deptId and deptName columns. Employee will have empId, name and deptId columns. DeptId column in both tables will define the relation between the tables. We are using SQL db to save the data as it is relational data.
4. High level design
The first diagram below shows a basic high level design we have come up with. There is a read/write server which reads the data from and writes the data to the database.
Now, as you know we must follow the single responsibility principle in our design. Thus, we separate the server according to the functionality. The second diagram below shows two separate servers as well as load-balancer for efficient distribution of load on the servers.
5. Scale the design
We have non functional requirements of our system as high availability and scalability.
For highly available system, there should not be any single point of failure, as it will result in downtime. For scalability, system should not have bottlenecks so that it can process huge amounts of data. Now lets improve our system with these principles.
- In our basic design our reader/writer server was single point of failure. It resolved when we created 2 servers, one for read and one for write and added a load balancer so that there is a single point of entry for the outside world.
- Now load balancer becomes the single point of failure, so we add a redundant load balancer.
- Now the reader and writer although separate are single point of failures. So we create redundancies.
- Similarly for database we create its replica. For the purpose of load balancing on DB, we can use one for reading and other for writing. If anyone fails then the other takes over its functionality.
- Now if the system is read heavy like facebook, then we will need more read servers as they are a bottleneck for the system. So lets add more read servers.
- It might still be a bottleneck if there are more reads so we can introduce a cache before the read servers.
Refer below diagrams to see how we improved our system from a simple to a highly scalable and available system using the 3 principles of distributed system.
