![]() |
VOOZH | about |
Microservices is an architecture where an application is divided into small, independent services that communicate over a network. Instead of one tightly coupled codebase, each service handles a specific function and can be developed and deployed separately.
Example: An e-commerce platform like Amazon can be built using microservices, where separate services handle product catalog, user authentication, cart, payments, and order management. Each service works independently and communicates over APIs.
Microservices architecture is widely used in modern applications where scalability, flexibility, and independent service management are important.
The working of microservices architecture focuses on dividing the application into small, independent services that collaborate to perform different business functions.
Main components of microservices architecture include:
Microservices are independent, loosely coupled services designed around specific business functions.
The API Gateway serves as a centralized entry point for all external client requests.
Service Registry and Discovery keeps track of available services and their locations.
A Load Balancer distributes incoming traffic across service instances.
Technologies like Docker (Containerization) and Kubernetes are used to package, deploy, and manage microservices efficiently.
An Event Bus or Message Broker enables asynchronous communication between services.
In the Database per Microservice pattern, each microservice owns and manages its own dedicated database to maintain data autonomy.
Caching improves performance by storing frequently accessed data closer to services.
Fault tolerance and resilience mechanisms enable the system to continue functioning even when some components fail.
Below are the main design pattern of microservices:
API Gateway pattern simplifies the client’s experience by hiding the complexities of multiple services behind one interface. It can also handle tasks like authentication, logging, and rate limiting, making it a crucial part of microservices architecture.
Service Registery pattern is like a phone book for microservices. It maintains a list of all active services and their locations (network addresses). When a service starts, it registers itself with the registry.
Other services can then look up the registry to find and communicate with it. This dynamic discovery enables flexibility and helps services interact without hardcoding their locations.
In circuit breaker pattern If a service fails repeatedly, the circuit breaker trips, preventing further requests to that service. After a timeout period, it allows limited requests to test if the service is back online. This reduces the load on failing services and enhances system resilience.
Saga pattern is useful for managing complex business processes that span multiple services. Instead of treating the process as a single transaction, the saga breaks it down into smaller steps, each handled by different services.
If one step fails, compensating actions are taken to reverse the previous steps. This way, you maintain data consistency across the system, even in the face of failures.
In Event Sourcing Pattern, Each event describes a change that occurred, allowing services to reconstruct the current state by replaying the event history. This provides a clear audit trail and simplifies data recovery in case of errors.
Strangler pattern allows for a gradual transition from a monolithic application to microservices. New features are developed as microservices while the old system remains in use.
Over time, as more functionality is moved to microservices, the old system is gradually "strangled" until it can be fully retired. This approach minimizes risk and allows for a smoother migration.
Similar to compartments in a ship, the bulkhead pattern isolates different services to prevent failures from affecting the entire system.
If one service encounters an issue, it won’t compromise others. By creating boundaries, this pattern enhances the resilience of the system, ensuring that a failure in one area doesn’t lead to a total system breakdown.
When you need to gather data from multiple microservices, the API composition pattern helps you do so efficiently.
A separate service (the composition service) collects responses from various services and combines them into a single response for the client. This reduces the need for clients to make multiple requests and simplifies their interaction with the system.
CQRS Design Pattern divides the way data is handled into two parts: commands and queries. Commands are used to change data, like creating or updating records, while queries are used just to fetch data. This separation allows you to tailor each part for its specific purpose.
nderstand the Microservices using the real-world example of Amazon E-Commerce Application:
Amazon’s online store runs on many small, specialized microservices, each handling a specific task. Working together, they create a smooth shopping experience.
The microservices involved in Amazon E-commerce Application:
Below are the main the key steps to migrate from a monolithic to microservices architecture:
While microservices provide many benefits, they also introduce certain complexities that organizations must manage carefully.
Below is a tabular comparison between microservices and monolithic architecture across various aspects:
| Monolithic Architecture | Microservice Architecture |
|---|---|
| Single-tier architecture | Multi-tier architecture |
| Built as one large application with tightly coupled components | Composed of small, loosely coupled services components |
| Deployed as a single unit | Individual services can be deployed independently |
| Horizontal scaling can be challenging | Easier to scale horizontally |
| Development is simpler initially | Development is more complex due to multiple services |
| Technology stack choices are usually limited | Freedom to choose the best technology for each service |
| Entire application may fail if a part fails | Individual services can fail without affecting others |
| Easier to maintain due to its simplicity | Requires more effort to manage multiple services |
| Less flexible as all components are tightly coupled | More flexible as components can be developed, deployed, and scaled independently |
| Communication between components is faster | Communication may be slower due to network calls |