System Design
Importants
1.
1. Understanding of System Design
Well usually when we build a System( an entire application/software ) from scratch, there is actually some sort of background design behind it.
Lets see with the real world exapmple of opening a restaurant.
So lets begin with the example of pizza parlor and we only have just 1 chef, so there must be a time comes where 1 chef can't control all the orders, which are given by customers
Q => A quick question for you, how can u control more orders?
Ans.
-> Obviously, if you think like a manager then the first thing u can do is that u ask the chef to work hard and pay him more( more input of money then output of pizzas by chef ), or either you can increasing the number of chefs or you can increasing the number of restaurants.
-> So if we ask for chef to work hard, then in technical terms we can think of chef as a computer then this is like, Optimise processes and increase throughtput using the same resources. This process is known as VERTICAL SCALING.
-> There is an another way to solve this problem of controlling more orders by preparing before hand at non peak hours, making large number of pizza bases and stuffing of pizza. This process is PRE-PROCESSING.
Now the system is setup, lets make it Resilient( recovering from failure quickly ), let say the chief is sick for few days.
Then what we can do is, we can hire a backup chef for those few days in which the main chef is sick, and we can pay him. This is like keeping backups and avoiding the single point of failure. This is known as MASTER SLAVE ARCHITECTURE. [Having Backups]
The other thing which we can do to make our system more Resilient is, we can hire more chefs, like 3 chefs and 2 chefs are in backup. We are increasing the number of resources of same type to get more work done. This is called HORIZONTAL SCALING.
Now the shop works perfectly fine, so its time for EXPENSION.
Lets say we have total of 3 chefs ie. chef 1, chef 2 and chef 3. Now chef 1 and chef 3 are good in making pizza's and chef 2 is good in making garlic bread.
Q => A quick question for you, On receiving an order, which chef should we assign to make which stuff?
Ans.
What we can do is, we can randomly assign them the orders to chefs, like garlic bread orders can go to chef 1 and pizza orders can go to chef 2, but this is not the most efficient way to use your employees. But this is not the most efficient way to use your employees, we can build on there strengths and route all garlic bread orders to chef 2 and all pizza orders to chef 1 and 3, this makes the system more simpler because any time u want to make some changes in recipe for garlic bread or if we need the status of order of garlic bread then u can just ask the chef 2.
Or we can actually make a team of chefs of here, like instead of chef 2, we can have a team of chef 2( consisting of 3 members ) for making garlic bread and instead of having chef 1, we can have a team of chefs1( consisting of 4 members ) for making pizzas and instead of having chef 3, we can have a team of chef 3( consisting of 3 members ) also for making pizzas... what we are doing here is, we are scaling each teams at different rate and also dividing the responsibilities. This is called MICROSERVICES ARCHITECTURE. ie. We are dividing the work and responsibilities on each Microservices, so that on thing dont effect other one.
Now this business is fully extendable to a large scale.
Q => What if there is an electricity outage in this pizza shop then obviously we won't have business that day or what if, you lose your license that day then also u wont have business that day?
Ans.
So what u wanna do is u want to distribute this system. We can open a new shop as a backup, in a different place which can also deliver the same stuff, may be it takes more time or there are less number of chefs but atleast u have a backup. This is probably the biggest step where we are introducing the complexity to the system because sometimes we needs the communication between these shops, u need to be able to route your requests, i mean if u get the request for the order of pizza, so should i send it to main branch or backup branch. This is called DISTRIBUTED SYSTEMS.
NOW,
Lets Say we have 2 pizza shop( PS1 and PS2 ) and Customers and Delivery Agents, everytime the customer makes a request, they need to send it, either on PS1 or PS2 but customers is not going to take that responsibilty, so u will send those request to somebody else, maybe to a central place which will handle all the route requests and u just don't want to send these request randomly.
you have a very clear parameter( how much time does it take for customer to get the pizza ), so if u send the order request to PS1( its a very popular shop ) therefore it takes 1 hour in queue + 5 mins to make pizza + 10 mins to deliver it => total time is 1 hour 15 mins, but let suppose if u send the order request to PS2( less popular shop ) therefore it takes 15 mins in queue + 10 mins to make + 40 mins to deliver it => total time is 1 hour 5 mins... therefore central authority should send it to PS2. This thing the managing of route request in a smart way is known as LOAD BALANCER.
At this point we can easily say that pizza shop and delivery agent have nothing in common. I mean it could be a pizza shop or it could be burger shop, this thing doesn't matter to delivery agent, delivery agents just want to deliver the goods as quickly as possible and similarly pizza shop doesn't matter, whether there is a delivery agent or customer to pick the pizzas. So we can see some sort of separation of responsibilities in shop and delivery agent, instead of having same managers managing the pizza shop and delivery agents at the same time, u want to separate that out, its called DECOUPLING the system.
DECOUPLING => Separating out the concerns, so that u can handle saparate systems more efficiently.
NOW,
At this point what u want is, u want to log everything up, like u wanna see at what time something happened and what could be the next event, for example => Delivery guy bike got puchered or pizza oven is not working properly... so we are going to take those events and condence them and find the sense out of those events so that this wont happen again. This is know as LOGING AND MATRIX CALCULATIONS. This step contains Analytics + Auditing + Reporting + Mechine Learning.
The final and most important point is, to keep your system EXTENSIBLE, ie. as a backend engineer, u don't want to rewrite the code again and again to server a different purpose. For example this delivery agent don't need to know that they are delivering a pizza, it can a burger tomorrow and if u think about the amazon, earlier they only deliver the parcels... The reason why u can scale your System is because u want to DECOUPLE everything to make sure that your system is EXTENSIBLE.
What we have done is taken up the business cenerio and try to find solution for all of these and then just map them into technical terms... If u think of these then they are solutions in themselfs for the techinal counter parts for these problems.
Finally we are manage to scale our restaurant, at a high level we can now define what kind of problems we face and how we will be solving them. This is known as HLD( HIGH LEVEL DESIGN ). HLD is like deploying on servers and figuring out How two systems will be intracting with each other.
There is a counter part of it, known as LLD( LOW LEVEL DESIGN ). Low Level System Design is lot more to do with how will u actually CODE this stuff like writing it efficiently and making classes and objects or Function for Designing the System.
2. SYSTEM DESIGN BASICS
Imagine you have computer with you, in which u have writen a algorithm, so some code is running on this computer and this code is like a normal function it takes an input and returns an output and people look at this code and decide that it is usefull to them and they will pay u to use it. Now the thing is u can't go around give your computer to every buddy so that they can use that code, now so what u do is u expose your code using some protocol which is going to be running on the internet and by exposing your code using API( Application Programmable Interface )... When your code does run then it will give an output and instead of storing it in a file or storing it on a DataBase, you simply return that output and thats called a RESPONSE and that protocal you are sending to server is known as REQUEST.
Now lets imagin setting up this computer => This might require a database to be connected to it within a desktop itself and you might require to configure those endpoints in which people are connecting to and you also need to take considration that what happens if there is a power loss, because u can't affort to have your service go down because there are lots of people paying for your services, Thats why you should host your services to the cloud.
So what's the difference between Desktop and a Cloud => Nothing really, Cloud is just a set of computers that somebody provides you for some certain amount of money. So if you pay a cloud services like AWS( Amazon Web Services ) which is the most popular one, if you pay for it then it will give you computation power, computation power is nothing but just a computer which they have setup somewhere and it can run your algorithm for 24X7. How will you actually store your algorithm in that computer, So you can do remote login into that online computer.
The reason why we use the cloud is, because the configure, setting, relaibility can be taken care up to a large extend by the solution providers( AWS ) and now we have a server which is hosted on cloud, we can focus on business requirement.
What business requirement do we possibly have?
Well now there are lots of people using algorithm now( basically your customers ), and the load on the server will be keep increasing as per the user increases then at some point your machine( cloud computer ) won't be able to handle the number of request which is coming in.
Then what we can do is, we can buy a bigger machine or we can buy more number of machines.
The ability to handle more number of requests by buying bigger machine or more number of machines is known as SCALABILITY.
1. Horizontal vs. Vertical Scaling
Feature | Horizontal Scaling | Vertical Scaling |
---|---|---|
Definition | Adding more machines/instances to a system | Increasing the capacity (CPU, RAM) of a single machine |
Also Known As | Scaling out | Scaling up |
Example | Adding more servers behind a load balancer | Upgrading server from 16 GB RAM to 64 GB RAM |
Cost | Higher upfront infra complexity; cost grows with more machines | Cheaper short-term, expensive long-term upgrades |
Fault Tolerance | Better (failure of one node doesn't impact others) | Poor (single point of failure) |
Maintenance | More complex (requires distributed systems, load balancing, etc.) | Simpler to manage (fewer nodes) |
Performance Limit | Scales well (can add more machines as needed) | Has hardware limits (CPU/RAM has a ceiling) |
Use Case | Web servers, distributed databases, microservices | Single-instance apps, monolithic systems |
Data Consistency | Harder to manage (needs distributed consensus) | Easier (single source of truth) |
Latency | Might increase (network hops between machines) | Usually lower latency (local operations) |
Resilience | High (no single point of failure if done right) | Low (downtime if the machine fails) |
Scalability | Virtually infinite (cloud providers offer auto-scaling) | Limited by hardware constraints |
Latency => It refers to the delay between an action and its corresponding reaction or response.
So what do you think, which we use in the real world? The answer is both... We take some good qualities of Vertical Scaling ie. really fast inter process communications and the data being consistent, and we take some good qualities of Horizontal Scaling ie. It scales well as per the number of user increase and its very resilient.
The hybird solution is generally the Horizontal scaling only where each machine, you try to take as bigger box as possible as feasible, money wise. Initially you can Vertical scale as much as you like, later on when your user is trusting you, then u should go for Horizontal scaling.
Comments
Post a Comment