Microservices Using the Saga Pattern

The Saga Pattern is one of the 6 Important Data Management Patterns of microservices. At it's very core, the Saga Pattern can be seen as a direct result of the database-per-service pattern.

In the database-per-service pattern, each microservice is responsible for its own data. However, this leads to an interesting situation. What happens when a business transaction involves data that spans across multiple microservices?

That is where the need for the Saga Pattern arises.

What Is the Saga Pattern?

The Saga Pattern is as microservices architectural pattern to implement a transaction that spans multiple services.

A saga is a sequence of local transactions. Each service in a saga performs its own transaction and publishes an event. The other services listen to that event and perform the next local transaction. If one transaction fails for some reason, the saga also executes compensating transactions to undo the impact of the preceding transactions.

Let's see a simple example in a typical food delivery app flow.

When a user places an order, below could be the sequence of actions that happen.

• The food ordering service creates an order. At this point, the order is in a PENDING state. A saga manages the chain of events.
• The saga contacts the restaurant via the restaurant service.
• The restaurant service attempts to place the order with the chosen restaurant. After getting a confirmation, it sends back a reply.
• The saga receives the reply. And depending on the reply, it can approve the order or reject the order.
• The food order service then changes the state of the order. If the order was approved, it would inform the customer with the next details. If rejected, it will also inform the customer with an apology message.

As you can see, this is a pretty different approach from the usual point-to-point call approach in typical workflows.

Types of Sagas

There are two types of Sagas:

Orchestration-Based Saga

In this approach, there is a Saga orchestrator that manages all the transactions and directs the participant services to execute local transactions based on events. This orchestrator can also be though of as a Saga Manager.

Choreography-Based Saga

In this approach, there is no central orchestrator. Each service participating in the Saga performs their transaction and publish events. The other services act upon those events and perform their transactions. Also, they may or not publish other events based on the situation.

Advantages and Disadvantages of the Saga Pattern

The main benefit of the Saga Pattern is that it helps maintain data consistency across multiple services without tight coupling. This is an extremely important aspect for a microservices architecture.

However, the main disadvantage of the Saga Pattern is the apparent complexity from a programming point of view. Also, developers are not as well accustomed to writing Sagas as traditional transactions. The other challenge is that compensating transactions also have to be designed to make Sagas work.

In my opinion, Sagas can help solve certain challenges and scenarios. They should be adopted or explored if the need arises. However, I would love to hear if others have also used Saga Pattern and how was the experience? What frameworks (if any) did you use?