A saga is described (according to Garcia-Molina and Salem) as a sequence of operations where each operation can be interleaved with other operations.
Each operation that is part of a Saga represents a single unit of work that can be undone after it is completed.
The operation can be undone by executing a compensation action. Let’s dive deeper using the following sub-topics.
- How Sagas Work
- Eventual Consistency Model
- Compensating Transactions
- Introducing the BASE Principle
- CAP Theorem
- Distributed Sagas
1. How Saga Works
A saga is created by splitting up some transaction into a sequence of operations.
For example, placing an order could consist of three operations:
- Create Order
- Reserve Credit
- Verify Customer Address
- Confirm Order
In this case, if the other is created but the credit could not be reserved, then the order should be undone (or canceled). Similarly, if the order is created and credit is reserved but th address could not be verified, then the previous two action should be undone.
Executing the operations as a transaction guarantees the ACID(Atomicity, Consistency, Isolation, Durability) property of the data storage.
2. Eventual Consistency Model
A saga utilizes the eventual consistency model. This means that before the saga completes, the system may be in a temporary inconsistent state. This happens due to the possibility to commit a partial transaction, thereby breaking the Isolation property. The result is that intermediate changes are available before the saga ends. So this is one of the not-too-serious issues of saga in microservices. Nevertheless, eventual consistency is guaranteed.
3. Compensations (Compensating Transactions)
Remember for the saga pattern to succeed, then if one of the operations in the sequence fails, then we must roll back all previous operations.This means that for each operation, we must have a corresponding compensation action. This compensation is responsible for ‘undoing’ an earlier operation if needed.
As mentioned in (The Saga Pattern in a Reactive Microservices Environment by Matin Stefanko et al), the compensation action is not neccessarily a contradictory action the puts back the system in the original state. For example, a sent email cannot be unsent. However, a compensating action could be to send a second email that says that the previous is not valid.
4. Introducing BASE Principle
As mentioned before, the saga pattern supports not consistency but eventual consistency. So strictly speaking the saga pattern does not conform to the ACID principle. It aligns with the BASE principle since it relaxes the ACID requirement.
What is BASE?
According to research by Helland in 2009, modern application value availability over consistency. Therefore the system’s properties are:
BAsic Availability: This system is gives a higher priority to availability. Hence, availability is guaranteed for the most part
Soft State: This means that the state of the application may change at any time event without any immediate update request. This derives from eventual consistency
Eventual Consistency: This implies that the system could be in an inconsistent state, but if the system does not receive further modification requests, then it is guaranteed that the system will get into a consistent state.
5. The CAP Theorem
CAP theorem (also called Brewer’s Theorem) states that for a distributed data storage, it is not possible to achieve more than two of the following simultaneously: Consistency, Availability and Partition Tolerance.
Since you know the first two, I would just briefly explain Partition Tolerance. This means that the system continues to operate regardless of messages being dropped by the network between the nodes. Simply put, the system continues to function despite some kind of momentary failure between the services. When failure occurs, simply cancel the current operation and continue with the next, thereby achieving availability. Another option would be to force the failed operation
6. Distributed Saga
Before I round off this article, I think I should also briefly explain the concept of Distributed Sagas since we are talking about sagas in microservices.
Similar to what has been discussed for non-distributed saga, Saga can also be defined in distributed systems to be defined as a sequence of requests that are being placed on particular participants invocations. Management of distributed sagas would require a transaction log and a Saga Execution Component(SEC). However, the general principles of sagas also apply to distributed sagas as well.