Microservices: Saga Pattern

This article will help you to get to understand the followings in a better way:

- What is “Saga”?
- Why and where we need Saga?
- How to use Saga?
- What important points to be considered while saga Implementation?
Note: Beware of taking care of Technical error while using Saga Pattern.

Saga: The term ‘saga’ was coined by Hector Garcia-Molina in 1987.

What is Saga?
It's a mechanism that divides long-lived, distributed transactions into quick ones with compensating actions for recovery.
It's a useful way to implement eventually consistent transactions.
Saga focuses mainly on transactional aspects of atomicity and consistency.

Background and Problem
In microservice, we usually say that each service must have its own database. However, some business transactions span multiple services. But how to model our business transactions that require inputs from multiple services?
e.g.
- Money transfer from one bank to another.
- Online food delivery system.

Traditional approach: is using distributed transactions across multiple services, databases or message brokers. It uses 2PC(2 phase commit) to ensure whether the transaction either is committed or rolled back.

Problems using Distributed Transactions:
- Many modern technologies are not being supported by Distributed transactions e.g. Kafka or rabbitMQ (message brokers), Cassandra(NoSQL database) is not being supported.
- In order to commit using the traditional approach, all the required services need to be available and it forms a synchronous IPC, which reduces the total availability.

Solution:
To solve the complex problem of maintaining consistency, we need to use a mechanism that is based on the concept of loose coupling and asynchronous services.
Here sagas come into the picture to provide an effective and robust solution to this.
Define a saga for each system that needs to update data in multiple services. Saga is a sequence of local transactions. Each local transaction updates the data within the single service and to maintain data consistency these services coordinate with each other using asynchronous messaging.
Sagas don’t follow the ACID properties as they lack isolation, which means it only follows ACD properties.

As of now, we understood that local transaction commits takes place, so it needed to have compensating transactions too for rollback using compensate request meaning Saga manage itself for failure management when needed.
Compensation requests are idempotent.

How does Saga work?
For implementing sagas, the saga pattern requires a cycle log, which basically records the start of a saga and also all the requests. The process is coordinated using the Saga Execution Coordinator(SEC)

Types of SEC:

1. Choreography based — Distribute the decision making and sequencing among saga participants/services. They primarily communicate by exchanging domain events. The triggering service will not be aware of how other services are communicating with each other but in the end, it will get the response.

2. Orchestration based — Saga’s coordination logic is kept in Centralize orchestrator which sends the command messages to services telling them which service has to perform which operation. The triggering service will always be aware of how other services are communicating with each other and it will also get the response.

Most Important points to be considered while implementing Saga Pattern:
- Only be used to roll back transactions logically, occurred due to business errors.
- Saga Pattern doesn’t deal with technical errors.

Explanation:

Saga Pattern is most popular in the Payment session(fintech domain).
Let’s take up a scenario where I as a customer trying to use an expired credit card, will get the error saying your Card is no more Valid. This is part of violating business validation — Saga Worked 👍🏼

But what if I am using a valid Prepaid card with a future expiration date but also not having sufficient money in it. I started doing shopping but at the time of reading/writing the database something technical error happened (could be an infrastructure issue) and at this moment the event got lost somehow then the rollback of the transaction will not be possible but the transaction will take place meaning my order got placed successfully. In this case, the Saga Pattern 👎🏻 failed.