Ask the good questions and define the Minimum Viable Product(MVP) for the system Design Problem.
A problem can have many features, it’s our responsibility to work with the owner and figure out which features he cares about and which features he doesn’t care about.
We need to remember that we are working under a very strict time frame, so we need to make sure our feature set is small and go deep into this feature set.
How much to scale ?
How much data we need to store in the database?
How many requests/second need to be handled?
What kind of latency is expected from the system?
Don’t Use Buzzwords
Make sure whatever technologies or concept we are mentioning we do have some sort of in-depth knowledge on those technologies.
Clear and Organized Thinking
Before jumping into the minor details of the problem first we need to try to define the 50,000 feet view of the problem.
Need to make sure we have defined all the APIs.
Need to make sure we have drawn right boxes.
Need to make sure we know who are the actors for the system.
Once we have defined all those things then we go deeper into the details working with the product owner.
Drive Discussions (80-20) Rule
We should be talking 80% of the time and the product owner should be talking 20% of the time.
Need to make sure we lead the discussions.
Need to make sure we anticipate the problems which are there in our solution and fix them pre-emptively.
Solving System Design
Solving system design questions could be broken down into three steps:
Scoping the problem : Don’t make assumptions; Ask clarifying questions to understand the constraints and use cases.
Sketching up an abstract design Illustrating the building blocks of the system and the relationships between them.
Identifying and addressing the bottlenecks by using the fundamental principles of scalable system design.
Note:- Remember there is no ONE right answer to the question because any system can be built in different ways. The only thing that is going to be looked into is your ability to rationalize ideas and inputs.
Whenever we are designing a large system, we need to consider few things:
What are different architectural pieces that can be used?
How do these pieces work with each other?
How can we best utilize these pieces, what are the right tradeoffs?
Note:- Investing in scaling before it is needed is generally not a smart business proposition; however, some forethought into the design can save valuable time and resources in the future.
Getting to know the Terminologies
Designing a Restaurant
Once restaurant starts working fine, pay more to chef to increase throughput using same resource — Vertical Scaling
Preparing beforehand during non-peak hours —- Preprocessing and Cron jobs.
Keeps backup and avoid single point of failure. — Backups (Master - Slave Architecture)
Hire more resources. — Horizontal Scaling
Divide responsibility and scale teams at different rate a/c to need. — Separation of concerns (Microservice Architecture)
Open new shop with similar functionality at a new location. — Distributed System (Partitioning) - Now Fault Tolerant
Routing request b/w shops when order received. — Load Balancer
Handling delivery agent and shops separately. — Separation of System (Decoupling) - Handle more effectively
If something goes wrong log it to take corrective action quickly — Logging and Metrics calculation
Delivery agent should not be bothered if they going to deliver pizza or burger tomorrow. — Extensible
High Level Design Vs. Low Level Design
In High level we mostly talk about server, architecture and all that.
Low level design deals with how we actually going to code these stuff.