In this tutorial, we are going to learn the evolution of microservice architecture.
Imagine we are running a large e-commerce website like Amazon. When a customer buys a product, a couple of things happen; browsing the product, placing the order, processing payment, updating inventory, etc.
Monolithic Architecture
Monolithic architecture is like a small all-in-one diner. One single person acts as a cook, waiter, cashier, etc.
Let's consider a simple e-commerce application which have multiple features, as shown in the diagram. Here, all the code for all the features will be packaged in a single giant application that will run in a single database.
The problem with this architecture is that if one of the services fails, the entire application will crash.
Service-Oriented Architecture (SOA)
SOA is like a food delivery app such as Uber Eats. When you order the food, you don't have to cook or drive to pick up the food. Different services work together via a central hub.
Here, the individual services have independent code. The order service doesn't care how the payment service works.
Each service is connected via a central hub called an Enterprise Service Bus (ESB). Instead of the services talking to each other, they do so through the ESB. For e.g if two services use different data formats, the ESB translates between them so they can understand.
The problem with this architecture is that the ESB can have a massive bottleneck. If the ESB fails, the services can't talk to each other, resulting in a single point of failure.
Microservices Architecture
Microservices architecture overcomes the different issues with the other architectures mentioned above.
It's like a food court inside the shopping mall; each restaurant, like Burger Hub, Pizza Place, etc act and serves independently. They have their own kitchens, cash, and staff.
Each business module is broken down into small, self-contained applications called microservices.
Here, no heavy central bus (ESB) is involved. Services talk to each other using lightweight protocols like REST or JSON, and an event message broker.
Each microservice has its own database. So, one service can't directly access another service's database.
Example: The Flash Sale Traffic Spike
Let's consider the store application starts a black friday sale. 100000 customers hit the website, but only 1k customers placed an order.
In a monolith application: When the 100k users search for the product, the system memory and the database might get overloaded. Due to this overload, 1k customer's payment requests might crash. As a result, we need to force the entire application to scale, which costs a lot in resources.
In Microservices Architecture:
- The product service got 100k requests
- The system automatically adds the required extra server instances, like 15/20, to handle the traffic.
- The order service and payment service will scale to 2/3 instances for processing with zero performance impact. This reduces the resource cost.
Conclusion
Monolithic architecture bundles everything together, easy to start out but hard to change and scale. SOA splits the code into services but totaly depend on the ESB that might cause a single point of failure under overload. Microservices separate their own app and domain, scaling to make the systems fast, flexible, and resilient.