System Design: Scaling a Pizza Shop
System desigining is nothing it as simple as you are thinking how manage software for different and different senarious you can think of a pizza shop where you want to scale up that pizza shop from 1 Store and one Chef.
The example we’re using in this entire blog is to open a pizza store and make it the biggest pizza store in India, or in simpler terms, scaling up the pizza store.
Vertical Scaling
We have a pizza parlor with one chef initially. I, Abhinav, am the founder and manager of this parlor. Now, I want to manage all orders and what I can do is pay the chef for overtime so that he can work more (this is just an example, I’m not like the CEO of Infosys). Let’s say he is able to handle things now while working overtime. In computer terms, this is called Vertical Scaling. It involves increasing CPU, RAM, and drive space in the existing computer, also known as optimizing processes and increasing throughput with the same resources.
Preprocessing
You can create pizza bases in non-peak hours, let’s say in the afternoon or late at night or early morning. In computer terms, we can schedule cron jobs to preprocess things when there is least or negligible traffic. So, you can serve better in peak hours using preprocessed things. Just like you don’t need to create a pizza base in peak hours, just use old prepared pizza bases.
Resilience (Backup)
Your chef is out of town or sick or may leave (you need some days to find a new chef), so you must have contact with a part-time chef for whom you can pay daily or weekly. The same goes for computers; let’s say one PC breaks, what will you do? You can’t lose customers or have your system crash, so you will have a backup system that may not need to be that efficient but at least somewhat efficient to manage for hours or days or weeks. The backup will help you resolve single point failures. In computer terms, Master-Slave architecture does the same when the master is unavailable, the slave will serve the needs.
Horizontal Scaling
Hire more chefs or in computer terms rent more servers (AWS, Azure, Google Cloud) or purchase more systems (Local Infrastructure).
Microservices
Let’s assume you have 10 chefs now after vertical scaling or hiring a new chef C1, C2, C3, C4, C5, C6, C7, C8, C9, C10.
C1, C5 specialize in pizza making: M1 Team.
C6, C8 specialize in Garlic Bread: M2 Team.
C9 and C10 specialize in Dessert: M3 Team.
We can call M1 as one microservice because it is independent of other teams and can be responsible for their own responsibilities. The same goes for other teams, so if one team member of one team fails or one team fails, it does not affect other teams and other functionalities. That’s the benefit of microservices. Let’s say pizza orders are increasing drastically, so instead of hiring a random specialization chef, we will hire only pizza maker specialized chefs. Similarly, let’s say one service is facing high demand, we will scale the infrastructure of that service instead of scaling the whole system.
Distributed System:
What if there is a flood in the area of the pizza shop, or an electricity outage, or the shop’s license gets cancelled? Will the business stop? No, we will open a pizza shop with a small team or a big team, depending on the requirement, in another locality so that at least we can provide service
(Yes, we are not WhatsApp. WhatsApp outage will be reported on Twitter or X, but we will scale bigger and smarter than WhatsApp).
We will create a backup server. Let’s say earlier we were using Azure as the main server, now we will use AWS as a backup server when Azure is at an outage. This is called distributed system design. Maybe the backup will not be as efficient as the main, but at least we are not totally blacked out.
Also, let’s say we distribute in different regions like Asia, Africa, etc. So whichever system is nearer will resolve your request to reduce latency. Isn’t it great?”
Load Balancing
There must be a single point where we can decide which customer order will go to which pizza shop because now we have three pizza shops. So, we will send it to that pizza shop where the total time (Wait + Bake + Pack + Delivery Time) is least. This will be decided by a single entity that, in computer terms, is called a Load Balancer. It will decide which request to send to which server according to availability, latency, etc.
Decoupling
How will you future-proof that maybe our pizza shop in the future serves only burgers or maybe we open one burger shop? So, how will you manage this? It’s done using decoupling. So, we will separate the responsibility. The customer doesn’t care who is delivering their pizza, just as the pizza shop doesn’t care who is taking the pizza, either the delivery guy or the customer. Similarly, the delivery guys don’t know what they are delivering, whether it’s a pizza, burger, or Litti Chokha. So, decoupling is introduced. We are having different managers for handling orders and handling delivery.
Logging and Metric Calculation
Let’s say the bike of the delivery guy gets punctured, or there’s some fight between customers at the pizza shop (Wow, what a scene!). So, we will analyze the situation, audit, report, and make decisions intelligently using ML or manually. The same goes for computers. Let’s say a server fails, one part of the server fails, some hacking happens, or anything, so you maintain a log, analyze the situation, audit it, and make decisions either manually or via ML or AI.
Extensibility
You don’t want to write code again and again, so make your code more modular. Or maybe in the future, some change happens, you can accommodate that change easily.
So many things you can think of now like :
- Order Overload : Recruitment of new interns with at least 3 years of experience excluding internships (Hahaha).
- Separation of Concerns to Reduce Complexity
- Mishaps: Fault Tolerance
Thanks for reading!
Connect with me at Linkedin.