Hardmicroservices
Microservices Patterns (SAGA, CQRS, API Gateway)
1. What is Microservice Architecture?
Definition
Microservice architecture develops every service as a separate project (executable app), nothing but REST application. So that we can activate or deactivate services as per our need. Each service is independently deployable, scalable, and maintainable.
Flipkart Project using MicroService Architecture:
Login & ShoppingService BillingService
Application [As Rest App] [As Rest App]
Service
[As Rest App] MS#2 MS#3
MS#1
Since each service is developed as separate Rest App, we can take
more instances of busy service and less instances for other/rarely used services.
Instance of service/App means a running copy the app/service.
e.g., Since Shopping service will be having more traffic and more
requests from more users, we will more instances for it. Only 60%
users who do shopping go for billing so we can take less no. of
instances for billing service. Only 20% users generally go for payment
so we more less no. of instances for payment service as needed.
Benefits of Microservice Architecture
- Scalability: ability to increase or decrease number of instances
- Flexibility: ability to use our choice one or more services together
- Independent and autonomous: ability to use each service in different projects
- Resilience: taking care of fail overs - if one service goes down, it diverts to another service
- Continuous integration and delivery: ability to have modifications and releases continuously
Microservice Design Patterns
To provide the above benefits, we can use the following microservice architecture design patterns:
- Database per MicroService
- Event Sourcing
- CQRS (Command Query Responsibility Segregation)
- SAGA
- API Gateway
- Circuit Breaker
- Externalized Configuration
- Consumer-driven Contract Tracing
2. Database Per Microservice
Problem: Shared Database (Anti-Pattern)
Anti-Pattern
Where all services together use same DB s/w or DB instance. Microservices using shared DB is anti-pattern. Note: Best solution for the problem is design pattern. Worst solution for the problem is called anti-pattern.
Anti-Pattern: Shared Database
MS#1 MS#2 MS#3 MS#4 MS#5
| | | | |
+------+------+------+------+
|
Database software
(single shared DB)
Cons:
- Microservices become non-scalable
(as data is increasing in multiple microservices
we need to change to DB s/w or increase RAM size and HDD size)
- Microservices lose their independent or autonomous behavior
- Microservices lose their portability
- All Microservices are forced to execute in same platform and environment
Pros:
- Transaction management becomes (Local Transaction Management sufficient)
Solution: Database Per Service (Design Pattern)
Design Pattern: Database Per Service
MS#1 <--> MS#2 <--> MS#3 <--> MS#4
| | | |
DB s/w DB s/w DB s/w DB s/w
Every Micro service will use separate DB s/w or instance.
Pros:
- Each service DB s/w can be made scalable
- Each Service (MS) domain data is encapsulated,
one Service (MS) cannot get other service (MS) data
- Understanding service, enhancement of service becomes easy
- Suitable for new developers for MS project
- Services become independent and autonomous
- Some services can use SQL DBs and some other services
can use No SQL DBs as needed based on format of the data
- Different MS can be placed in different platforms because
they have their own DB
Cons:
- We definitely need Distributed TransactionManagement support
that runs on 2PC (two phase commit protocol)
Conclusion
In Micro service architecture, every service (MS) should have separate DB s/w or Logical DB or DB Instance or Schema having all DB tables.
Note: In Monolithic App (all services as modules as single App/Project), we prefer this kind of single or shared DB s/w. But in MicroServices, we prefer Database per service.
3. SAGA Pattern
Definition
In Microservices, each service has its own database. So the traditional local transaction (single DB) does not work across services. SAGA is a pattern for managing distributed transactions across multiple microservices. Each service performs its local transaction and publishes an event. If any step fails, compensating transactions are executed to undo the previous steps.
Two Types of SAGA
| Type | Description | Coordinator |
|---|---|---|
| Choreography | Each service publishes events and listens for events from other services. No central coordinator. Services decide on their own what to do based on events. | None (event-driven, decentralized) |
| Orchestration | A central orchestrator (SAGA coordinator) tells each service when to execute its transaction. The orchestrator manages the flow. | SAGA Orchestrator service |
SAGA Orchestration Example: Order Processing
SAGA Orchestrator
(central coordinator)
/ | \
v v v
Order Service Payment Shipping
(step 1: Service Service
create order) (step 2: (step 3:
charge) ship)
Success flow: create order -> charge payment -> ship order -> DONE
Failure flow: create order -> charge payment FAILS ->
compensate: cancel order (undo step 1)
Each step has a compensating transaction:
create order <--> cancel order
charge payment <--> refund payment
ship order <--> cancel shipment
4. CQRS Pattern (Command Query Responsibility Segregation)
Definition
This pattern is good along with Event Sourcing pattern. This pattern says: separate read operations and write operations that are happening on the DB s/w or any Repository by taking different Services.
CQRS: Separate read and write services
write operations
UI ---> Service1 ---------> DB s/w
|
+--> Service2
read operations
Example Scenario:
Payment Service ---write---> [DB]
UI /
\--> Order / read
\ Overview ---> Shipping Service ---write---> [DB]
\ Service \
\ \ read
\ +--> Order Service ---write---> [DB]
Note: Instead of payment, shipping, order MS talking with each other and mixing
read and write operations on DB s/w or Event Logs or Event Repository, the CQRS
pattern says develop separate MS talking to these related Services to get
the necessary information and to present to enduser through UI.
CQRS combined with Event Sourcing
According to Event Sourcing pattern, every business activity will be treated as one event, and all these events will be written to Event Log Repository.
Event Sourcing + CQRS:
payment service ----write----> [Event Log Repository]
/ (immutable)
Order /
Overview ---+--- Shipping Service --write--> [Event Log Repository]
Service \ (immutable)
(reads \
the state) +--- Order Service ---write--> [Event Log Repository]
(immutable)
All these Event Log Repositories
maintain business operations as events.
Event Sourcing says: MS should write their business operations as events.
CQRS says: develop separate MS for Reading data and separate MS for writing data.
5. API Gateway Pattern
Definition
API Gateway is a tool that traps and routes all the requests and delegates to specific other services by applying common logic on trapped requests and responses.
Problem: Microservice Architecture without API Gateway
Browser --> Flipkart-order.com (Order Service)
Mobile --> Flipkart-shopping.com (Shopping Service)
--> Flipkart-Payment.com (Payment Service)
UI should use different domain names in order to interact with
different services. Remembering multiple domain names to use
multiple service is quite hard approach. To overcome this use API Gateway.
Solution: API Gateway
Browser --> api.flipkart.com --> Order Service (Flipkart-order.com)
Mobile --> --> Shopping Service (Flipkart-shopping.com)
--> Payment Service (Flipkart-Payment.com)
For enduser one URL:
If we request flipkart/order then request to order service
If we request flipkart/shopping then request to shopping service
If we request flipkart/payment then request to payment service
(we can access all the services using the common domain flipkart/*)
API Gateway is a tool that traps and routes all the requests and delegates to specific
other services by applying common logic on trapped requests and responses.
e.g.: Netflix Zuul, Spring Cloud Gateway, Kong Gateway, Apigee and etc.
Advantages of API Gateway
- Common Authentication: at API gateway level
- Response caching: if same request comes to same MS for multiple times with same inputs, the response will be kept in cache and will be used multiple times
- Load balancing: we can take multiple instances of each service, so API gateway picks less load instance because of its load balancing
- Metrics Collection: since API gateway traps all requests and responses, so we can get no. of requests, no responses, request processing time, etc.
- Circuit Breaker: if any problem comes while executing any service, it automatically diverts to another service
- Common URL/URI: for accessing all the services
6. All Patterns Comparison
| Pattern | Solves | Mechanism | Tools |
|---|---|---|---|
| Database Per Service | Data coupling between services | Each MS has its own DB | MySQL, PostgreSQL, MongoDB (per service) |
| SAGA | Distributed transactions | Local transactions + events + compensation | Axon Framework, Eventuate, custom orchestrator |
| CQRS | Read/write performance bottleneck | Separate read and write services | Axon, custom event store |
| Event Sourcing | Audit trail, state reconstruction | Store events instead of current state | Kafka, EventStore, Axon |
| API Gateway | Multiple entry points, cross-cutting concerns | Single entry point routing to services | Spring Cloud Gateway, Kong, Netflix Zuul, Apigee |
| Circuit Breaker | Cascading failures | Fail fast when service is down | Resilience4j, Hystrix (deprecated) |
Microservices
Advanced
Microservices Design Patterns
1. What is Microservice Architecture?
Definition
Microservice architecture develops every service as a separate project (executable app), nothing but REST application. So that we can activate or deactivate services as per our need. Each service is independently deployable, scalable, and maintainable.
Flipkart Project using MicroService Architecture:
Login & ShoppingService BillingService
Application [As Rest App] [As Rest App]
Service
[As Rest App] MS#2 MS#3
MS#1
Since each service is developed as separate Rest App, we can take
more instances of busy service and less instances for other/rarely used services.
Instance of service/App means a running copy the app/service.
e.g., Since Shopping service will be having more traffic and more
requests from more users, we will more instances for it. Only 60%
users who do shopping go for billing so we can take less no. of
instances for billing service. Only 20% users generally go for payment
so we more less no. of instances for payment service as needed.
Benefits of Microservice Architecture
- Scalability: ability to increase or decrease number of instances
- Flexibility: ability to use our choice one or more services together
- Independent and autonomous: ability to use each service in different projects
- Resilience: taking care of fail overs - if one service goes down, it diverts to another service
- Continuous integration and delivery: ability to have modifications and releases continuously
Microservice Design Patterns
To provide the above benefits, we can use the following microservice architecture design patterns:
- Database per MicroService
- Event Sourcing
- CQRS (Command Query Responsibility Segregation)
- SAGA
- API Gateway
- Circuit Breaker
- Externalized Configuration
- Consumer-driven Contract Tracing
2. Database Per Microservice
Problem: Shared Database (Anti-Pattern)
Anti-Pattern
Where all services together use same DB s/w or DB instance. Microservices using shared DB is anti-pattern. Note: Best solution for the problem is design pattern. Worst solution for the problem is called anti-pattern.
Anti-Pattern: Shared Database
MS#1 MS#2 MS#3 MS#4 MS#5
| | | | |
+------+------+------+------+
|
Database software
(single shared DB)
Cons:
- Microservices become non-scalable
(as data is increasing in multiple microservices
we need to change to DB s/w or increase RAM size and HDD size)
- Microservices lose their independent or autonomous behavior
- Microservices lose their portability
- All Microservices are forced to execute in same platform and environment
Pros:
- Transaction management becomes (Local Transaction Management sufficient)
Solution: Database Per Service (Design Pattern)
Design Pattern: Database Per Service
MS#1 <--> MS#2 <--> MS#3 <--> MS#4
| | | |
DB s/w DB s/w DB s/w DB s/w
Every Micro service will use separate DB s/w or instance.
Pros:
- Each service DB s/w can be made scalable
- Each Service (MS) domain data is encapsulated,
one Service (MS) cannot get other service (MS) data
- Understanding service, enhancement of service becomes easy
- Suitable for new developers for MS project
- Services become independent and autonomous
- Some services can use SQL DBs and some other services
can use No SQL DBs as needed based on format of the data
- Different MS can be placed in different platforms because
they have their own DB
Cons:
- We definitely need Distributed TransactionManagement support
that runs on 2PC (two phase commit protocol)
Conclusion
In Micro service architecture, every service (MS) should have separate DB s/w or Logical DB or DB Instance or Schema having all DB tables.
Note: In Monolithic App (all services as modules as single App/Project), we prefer this kind of single or shared DB s/w. But in MicroServices, we prefer Database per service.
3. SAGA Pattern
Definition
In Microservices, each service has its own database. So the traditional local transaction (single DB) does not work across services. SAGA is a pattern for managing distributed transactions across multiple microservices. Each service performs its local transaction and publishes an event. If any step fails, compensating transactions are executed to undo the previous steps.
Two Types of SAGA
| Type | Description | Coordinator |
|---|---|---|
| Choreography | Each service publishes events and listens for events from other services. No central coordinator. Services decide on their own what to do based on events. | None (event-driven, decentralized) |
| Orchestration | A central orchestrator (SAGA coordinator) tells each service when to execute its transaction. The orchestrator manages the flow. | SAGA Orchestrator service |
SAGA Orchestration Example: Order Processing
SAGA Orchestrator
(central coordinator)
/ | \
v v v
Order Service Payment Shipping
(step 1: Service Service
create order) (step 2: (step 3:
charge) ship)
Success flow: create order -> charge payment -> ship order -> DONE
Failure flow: create order -> charge payment FAILS ->
compensate: cancel order (undo step 1)
Each step has a compensating transaction:
create order <--> cancel order
charge payment <--> refund payment
ship order <--> cancel shipment
4. CQRS Pattern (Command Query Responsibility Segregation)
Definition
This pattern is good along with Event Sourcing pattern. This pattern says: separate read operations and write operations that are happening on the DB s/w or any Repository by taking different Services.
CQRS: Separate read and write services
write operations
UI ---> Service1 ---------> DB s/w
|
+--> Service2
read operations
Example Scenario:
Payment Service ---write---> [DB]
UI /
\--> Order / read
\ Overview ---> Shipping Service ---write---> [DB]
\ Service \
\ \ read
\ +--> Order Service ---write---> [DB]
Note: Instead of payment, shipping, order MS talking with each other and mixing
read and write operations on DB s/w or Event Logs or Event Repository, the CQRS
pattern says develop separate MS talking to these related Services to get
the necessary information and to present to enduser through UI.
CQRS combined with Event Sourcing
According to Event Sourcing pattern, every business activity will be treated as one event, and all these events will be written to Event Log Repository.
Event Sourcing + CQRS:
payment service ----write----> [Event Log Repository]
/ (immutable)
Order /
Overview ---+--- Shipping Service --write--> [Event Log Repository]
Service \ (immutable)
(reads \
the state) +--- Order Service ---write--> [Event Log Repository]
(immutable)
All these Event Log Repositories
maintain business operations as events.
Event Sourcing says: MS should write their business operations as events.
CQRS says: develop separate MS for Reading data and separate MS for writing data.
5. API Gateway Pattern
Definition
API Gateway is a tool that traps and routes all the requests and delegates to specific other services by applying common logic on trapped requests and responses.
Problem: Microservice Architecture without API Gateway
Browser --> Flipkart-order.com (Order Service)
Mobile --> Flipkart-shopping.com (Shopping Service)
--> Flipkart-Payment.com (Payment Service)
UI should use different domain names in order to interact with
different services. Remembering multiple domain names to use
multiple service is quite hard approach. To overcome this use API Gateway.
Solution: API Gateway
Browser --> api.flipkart.com --> Order Service (Flipkart-order.com)
Mobile --> --> Shopping Service (Flipkart-shopping.com)
--> Payment Service (Flipkart-Payment.com)
For enduser one URL:
If we request flipkart/order then request to order service
If we request flipkart/shopping then request to shopping service
If we request flipkart/payment then request to payment service
(we can access all the services using the common domain flipkart/*)
API Gateway is a tool that traps and routes all the requests and delegates to specific
other services by applying common logic on trapped requests and responses.
e.g.: Netflix Zuul, Spring Cloud Gateway, Kong Gateway, Apigee and etc.
Advantages of API Gateway
- Common Authentication: at API gateway level
- Response caching: if same request comes to same MS for multiple times with same inputs, the response will be kept in cache and will be used multiple times
- Load balancing: we can take multiple instances of each service, so API gateway picks less load instance because of its load balancing
- Metrics Collection: since API gateway traps all requests and responses, so we can get no. of requests, no responses, request processing time, etc.
- Circuit Breaker: if any problem comes while executing any service, it automatically diverts to another service
- Common URL/URI: for accessing all the services
6. All Patterns Comparison
| Pattern | Solves | Mechanism | Tools |
|---|---|---|---|
| Database Per Service | Data coupling between services | Each MS has its own DB | MySQL, PostgreSQL, MongoDB (per service) |
| SAGA | Distributed transactions | Local transactions + events + compensation | Axon Framework, Eventuate, custom orchestrator |
| CQRS | Read/write performance bottleneck | Separate read and write services | Axon, custom event store |
| Event Sourcing | Audit trail, state reconstruction | Store events instead of current state | Kafka, EventStore, Axon |
| API Gateway | Multiple entry points, cross-cutting concerns | Single entry point routing to services | Spring Cloud Gateway, Kong, Netflix Zuul, Apigee |
| Circuit Breaker | Cascading failures | Fail fast when service is down | Resilience4j, Hystrix (deprecated) |