Microservices Design Patterns

If you are preparing for an interview or just trying to get started with a Microservice then you should be aware of some of the design patterns which can be used to make your microservices resilient and useful.

Principles Used to Design Microservice Architecture

The principles used to design Microservices are as follows:

1. Independent & Autonomous Services
2. Scalability
3. Decentralization
4. Resilient Services
5. Real-Time Load Balancing
6. Availability
7. Continuous delivery through DevOps Integration
8. Seamless API Integration and Continuous Monitoring
9. Isolation from Failures
10. Auto -Provisioning

 These are some of the Microservices Design Patterns

1. Retry Pattern
   In this pattern we try to retry to request to another microservice for certain number of time in case there is a failure before return a failure status to the client.
   
   
2. Circuit Breaker Pattern
   In this pattern the microservices will keep track on the number of times a service returns failure. In case the number of failures goes above a threshold then the circuit opens and starts returning error for the calling service. The circuit breaker will keep on checking the failing service. Once we get a success then the circuit will close again so that the traffic can go to the service which was failing previously.
   
   
   
   
   
   
   
   
   
3. Bulkhead Pattern
   The patterns helps in isolating the services within a microservice from failure.
   
   
   
   
   
4. Aggregator Pattern
   The pattern is used to get the response from various microservices and the aggregate the result together.  
   
   
5. API Gateway
   The request first goes to the API gateway which routes the request to respective service based on the API Gateway.
   
   
6. Chained or Chain of Responsibility
   Chained or Chain of Responsibility Design Patterns produces a single output which is a combination of multiple chained outputs. So, if you have three services lined up in a chain, then, the request from the client is first received by Service A. Then, this service communicates with the next Service B and collects data. Finally, the second service communicates with the third service to generate the consolidated output. 
   
   
7. Asynchronous Messaging
   This pattern is used for asynchronous messaging between different microservices. We can add a messaging queue between the services. This pattern is helpful if we have a lot of requests coming and the service might need some time to process the request. 
   
   
8. Event Sourcing
   The event sourcing design pattern creates events regarding the changes in the application state. Also, these events are stored as a sequence of events to help the developers track which change was made when. So, with the help of this, you can always adjust the application state to cope up with the past changes. You can also query these events, for any data change and simultaneously publish these events from the event store.
   
   
9. Command Query Responsibility Segregation
   According to this pattern, the application will be divided into two parts: Command and Query. The command part will handle all the requests related to CREATE, UPDATE, DELETE while the query part will take care of the materialized views. 
   
   
10. Branch
    Branch microservice design pattern is a design pattern in which you can simultaneously process the requests and responses from  two or more independent microservices.
    
    
11. Saga Pattern
    This pattern helps with implementing a business transaction that spans multiple services. A saga is a sequence of local transactions. Each local transaction updates the database and publishes a message or event to trigger the next local transaction in the saga. If a local transaction fails because it violates a business rule then the saga executes a series of compensating transactions that undo the changes that were made by the preceding local transactions.
    

    There are two ways of coordination sagas:

• Choreography - each local transaction publishes domain events that trigger local transactions in other services
• Orchestration - an orchestrator (object) tells the participants what local transactions to execute
  https://medium.com/javarevisited/distributed-transaction-management-in-microservices-part-2-saga-pattern-53808a55e641
12. 2 Phase or 3 Phase Commit
    https://medium.com/javarevisited/distributed-transaction-management-in-microservices-part-1-bb7dc1fbee9f 
13. Backend for Frontend (BFF) design pattern
    BFF is a variant of the API Gateway pattern, but it also provides an additional layer between microservices and each client type separately. Instead of a single point of entry, it introduces multiple gateways
    Video : https://www.droidcon.com/2021/11/10/backend-for-frontend-the-secret-of-a-great-mobile-project/

Reference:

• https://medium.com/aspnetrun/microservices-resilience-and-fault-tolerance-with-applying-retry-and-circuit-breaker-patterns-c32e518db990 
• https://www.edureka.co/blog/microservices-design-patterns
  
• https://microservices.io/patterns/data/saga.html
• https://medium.com/trendyol-tech/saga-pattern-briefly-5b6cf22dfabc#:~:text=2PC%20works%20as%20a%20single,makes%20the%20data%20eventually%20consistent.
• https://medium.com/mobilepeople/backend-for-frontend-pattern-why-you-need-to-know-it-46f94ce420b0