System design - a high level overview
Table of contents
How many of us have tried to learn this complex process and then stopped thinking... this is too vast or I am doing well now, why set foot in this maze π.
Yup, been there , done that!
Now, lets take some action π― rather than this procrastination, right!
So, let's first start we a basic overview of System Design by taking a real life example.
Let's say we have a Pizza shopπ. And currently we have just one chefπ§βπ³
Now let's talk about cases one by one :
We have a increase a sales of about 10% πΉ because of new customers for a month now.
Solutions
Since the increase percentage is a small number, we can ask the existing chef to work more with increased compensation π€π°.
Congrats you've been introduced to the concept of Vertical Scaling ππ**.**Prepare the pizza base at non peak hours.
This is the processing that we do we scheduled jobs β° which need not be handled right away as these processes are not critical, and can be handled at a fixed time everyday, every hour , every 3 hour...
The chef (one and only that we have) fell ill π·, we know we don't want to replace the chef entirely (because he is the star of the shopπ), but we need to have the shop working (Building resilient systems πͺποΈπͺ)
Solutions:- Hire a temporary replacement ππ§βπ³(back up) for the existing chef and maybe keep more such back-up chefs ππ§βπ³ ππ§βπ³ ππ§βπ³ to avoid last minute hassle .
This is the obvious solution of having a back-up.
- Hire a temporary replacement ππ§βπ³(back up) for the existing chef and maybe keep more such back-up chefs ππ§βπ³ ππ§βπ³ ππ§βπ³ to avoid last minute hassle .
Now, the business is thriving ππΉπ€π° and the chef cannot alone handle the take-outs, deliveries and dine in orders. (Expanding the businessπ)
Solutions :- Hire more chefs obviously π§βπ³π§βπ³π§βπ³...
This is the concept of Horizontal scaling π**,** in which you get similar machines, to handle your workload. However this has led us to a new problem of distributing the load equally (optimal use of resources = money saved = money earned)
- Hire more chefs obviously π§βπ³π§βπ³π§βπ³...
So now we have 3 chefs namely Alex, John, Alice. Our business is thriving, but we know that John's speciality is garlic breadπ§π whereas Alex's and Alice's expertise is making pizzasπ. So now we have more information about the specialities of the chefs and we want to increase the business even more ππΉ.
So, if we have diverse orders , say order1 is for 3 pizzas and order 2 is for 2 garlic breads. How would you distribute these orders (routing intelligently)
Solutions:- Obvious solution knowing the expertise of the chefs is to send all the pizza orders to Alex , Alice and send all the garlic bread orders to John.
This is a microservice architecture π¦ π¦ π¦ my friends!
So, this solves a few more problems or simplifies them, so when you have to collect some data related to pizzas , you'd only approach the team pizzas i.e. Alex and Alice, similarly for garlic bread related queries you'll reach out to John.
Also if you know your this outlet is getting more of pizza orders, you'd hire more chefs specialised in pizza making π.
- Obvious solution knowing the expertise of the chefs is to send all the pizza orders to Alex , Alice and send all the garlic bread orders to John.
Now, we have 1 shop with 3 chefs and the system is pretty robust until we have some zonal issues like any localised disasters πͺοΈπ₯πππ₯π€―, but the business should go on ....
Solutions:So, now you can have at least 2 shops/outlets π¬ π¬, with a connection between these 2 shops. Say you have 2 chefs in the new shop.
This is called distributed systems. This makes your system more fault tolerant and available πͺ.This step introduces a lot of complexity in the whole system and adds a new problem of resource optimisation\β‘β .
Now, you want to be intelligently using these 2 shops. Such that when you get deliveries closer to shop2 you won't have shop1 prepare those.
Solutions:This is where the concept of load balancing π βοΈ comes into play.
So now you'll have someone with the required information to take orders for your whole business and then handle the orders accordingly .This doesn't only consider the distance, but also the wait time, the resource distribution, etc.
Now, that we have load balancing in place, we can consider some more problems like what if I have a cake shop ππ¬ as well and I don't want to have different teams to handle the deliveries of my 2 businesses(pizza and cake), as we know that not always will the delivery agents will be required but the pizza shop.
Solutions:- So, this is where we will have decoupling in the microservices, since the delivery agents team is also a specialised team doing only deliveries, we will remove the dependencies between the teams and have a layer of discretion (encapsulation)
We have a great system now π€©! But, what if something goes wrong in my pizza shop1, how do I know about it ?
How do I have a mechanism βοΈ set up after knowing that a shop doesn't deliver well when we have certain situations ?
Solutions:Here comes the need for logging and monitoring the events and errors logging eventsπ and converting those into ingestible and readable, knowledgeable information π.
This will help us know if a delivery agent π π΅ is not available for a day or if there is some infrastructure problem.
This can also help us try out some things for a specific duration and check the results and come up with new strategies.
Now, if you wish to open a new shop for something completely new like noodles, I want to be able to use the teams which are independent of cooking to be used in this new shop so we aim to make our system extensibleππ . This was done using the concepts of microservices, decoupling
In this blog, I have touched just the concept of High Level Design (HLD), I will go into its counter part Low Level Design(LLD) soon.
Congrats if you've read this far and thank you π!
Subscribe to my newsletter
Read articles from Srushti directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by