- Microservices Design Patterns Tutorial
- Microservices Design Patterns - Home
- Microservices Design Patterns - Overview
- Decomposition Design Patterns
- Decompose by Business Capability
- Decompose by Subdomain
- Decompose by Strangler
- Integration Design Patterns
- API Gateway
- Aggregator
- Proxy
- Client Side UI Composition
- Chain Of Responsibilities
- Branch
- Database Design Patterns
- Database per Service
- Shared Database per Service
- Command Query Responsibility Segregator
- Saga
- Aysynchronous Messaging
- Event Sourcing
- Observability Design Patterns
- Log Aggregation
- Performance Metrics
- Distributed Tracing
- Health Check
- Cross Cutting Concern Design Patterns
- External Configuration
- Service Discovery
- Circuit Breaker
- Blue Green Deployment
- Useful Resources
- Quick Guide
- Useful Resources
- Discussion
Chain of Responsibilities
Problem Statement
Microservice architecture structures an application as a set of loosely coupled microservices and each service can be developed independently in agile manner to enable continous delivery/deployment. Now if one service needs output of another service as dependency then how to handle such a case.
Solution
We can use Chain of Responsibilities Pattern. As the name suggests, this type of composition pattern will follow the chain structure. Here, we will not be using anything in between the client and service layer. Instead, we will allow the client to communicate directly with the services and all the services will be chained up in a such a manner that the output of one service will be the input of the next service. Following image shows a typical chained pattern microservice.
Disadvantage
One major drawback of this architecture is, the client will be blocked until the entire process is complete. Thus, it is highly recommendable to keep the length of the chain as short as possible.
