What is the Saga pattern in Microservice?

Saga model is one of the 6 important patterns of microservice data management that can be considered as a direct result of database-per-service pattern.I am going to familiarize you with the concept of Microservice using Saga Pattern. In the Database-per-service pattern, each Microservice is responsible for its data. However, the question is, what happens if a Transaction contains data that exists in multiple Microservice? It is in these situations that the need for the Saga model arises.

Saga pattern serves as the microservice architecture template for implementing transactions that include multiple services. Saga is the sequence of Microservices. Each service in a Saga performs its own Transaction and publishes an event. Other services listen to that event and perform the next local Transaction. If a Transaction fails for a reason, this template executes Compensating or Compensating Transactions in order to neutralize the impact of previous transactions.

As a simple example, we examine the steps in a food delivery program. When the user registers their order, the following steps can exist as actions taken: the food ordering service creates an order. At this point, the order is in PENDING mode. This template manages the chain of events and contacts the restaurant through the app and registers the order at the selected restaurant and sends the result to you after receiving approval from the restaurant. This template receives the answer and can confirm or reject the order according to the response received. Then the food ordering program changes the order status. If the order is confirmed, it will notify the customer of the next details and, if not accepted, will notify the customer with a message of apology.

As you can see, this method is quite different from the point-to-point approach.

Saga Types

There are two types of Saga:

  • Saga-based Orchestration

In this method, Saga orchestrator manages all transactions and, based on events, redirects Participant service to running transactions. This Orchestrator can also be considered as Saga Manager.

  • Saga-based Choreography

In this approach, there is no central Orchestrator. Each Participant service in Saga performs its own transactions and publishes events, and other services operate accordingly and perform their own Transactions. They may also publish or resent other events according to the circumstances.

Advantages and disadvantages

The main advantage of this template is that without Tight coupling it helps to maintain data Consistency during multiple services, which is a very important aspect of microservice architecture.

However, the main disadvantage of this pattern is having Apparent complexity in terms of programming. Also, developeres are not as accustomed to writing this template as traditional transactions. Another challenge is that compensating transactions are needed to operate Saga.

And in the end,

Mirbazorgi’s website aims to help you learn and fix your problems by providing articles and practical experiences. Email me if you have any questions.