One of the key challenges of the Microservices Architecture is in dealing with data consistency. In a Monolithic Application, it is possible to achieve data consistency easily using techniques such as 2 phase commits. In the Microservices Architecture on the other hand, achieving interdependent transactions across each microservice is difficult. For example, let us take a simple scenario of 2 microservices in an Insurance Management System. When a policy information is updated under the policy information column, the corresponding microservice premium needs to be updated under Microservices premium section. This is just a simple use case spanning two Microservices. In reality however, there could be scenarios involving multiple microservices. Coordinating such Microservice operations is difficult without making it chatty between each other and this is where the Saga pattern is of help.
Saga is a sequence of transactional messages achieved via event messages or API calls. Each message does some data storage updates and publishes events. If there is a failure in any of the messages, Saga invokes the compensation messages of the respective microservices. For this, it is imperative that the Microservices support roll back messages.
Saga can be achieved in two approaches which are listed below
Event choreography: This is a pattern where each successor in the saga sequence listens to the message of its predecessor to handle the operation. Microservices listens to both business events as well as the failure events and takes action accordingly.
Orchestration: Orchestration is a pattern where a separate process runs to orchestrate the messages between different microservices. This process runs as a separate unit or a combined one with any of the microservices. The Orchestrator listens to the initiating event which is triggered by a microservice and invokes the workflow.
While both has its pros and cons, it is usually better to adopt event choreography only when a very few number of microservices need to participate. Orchestration is a better choice when the process needs the involvement of many microservices.
It is very important to track the entire process so as to get a single view of the end to end Saga processes and hence troubleshoot issues. This needs to be accommodated into the design right from the very beginning.
Most complex use cases used to test Microservices are the orchestration of different microservices both in happy and alternate flows. So it is imperative that the Saga testing independent, automated from end to end and is a part of unit testing.
Many projects make the mistake of not including Saga pattern as a part of their design and this will lead to many complexities in the future. It is hence important to consider this from the very beginning of the architecture.
Latest posts by Jothi Rengarajan (see all)
- Predicting ROIs to a Microservices Migration – Sowing Seeds to Success - May 22, 2019
- The 4 Pillars of Microservices: Process – The Fulcrum of Strength (Part 1) - May 22, 2019
- Saga – The key differentiator of Microservices - April 26, 2019