Classification of SAGA transactions
According to the behaviors of the transaction, we can mainly identify 3 transaction types that can be happened when we use saga.
-
Success transactions
-
Compensating/Revert success transactions
-
Compensating/Revert failed transactions
Successful Transactions (Primary Execution Success Transactions)
GET_USER_DETAIL is not considered as an atomic transaction.
It’s just a query operation to get the user information. refer to Query Operation for more details.
|
Here we have 4 executions (3 atomic transactions) with 4 microservices. The entire transaction(Business transaction) will be completed after successfully executing the 4th atomic execution. All the primary executions are done successfully as we accepted those kind of transactions are called as Successful transactions.
Here is the summarized diagram for Success transaction.
Compensating Success Transaction
At this time, An exception occurred when make payment execution is executed. Then the primary executions process is stopped due to the error, and the compensating process is started to undo the successfully executed executions so far. And finally, the compensating process is also completed.
Even though this is a failed transaction from the business perspective, this is one of the successful transaction types from the Saga perspective. Because we have managed to keep the eventually consistent state by compensating the successfully executed transactions.
Here is the summarized diagram for compensating successful transaction.
Compensating Failed Transaction
At this time, An exception occurred when make payment execution is executed. Then the primary executions process is stopped due to the error, and the compensating process is started to undo the successfully executed executions so far. While then, unfortunately, an error occurred in compensating the process called CANCEL_ORDER.
| This scenario represents a theoretical edge case in distributed systems, developers should implement robust error handling to prevent compensating transaction failures. Compensating transactions must maintain idempotency and should only fail due to transient infrastructure issues such as Resource Unavailability problem. When encountering resource unavailability, implement exponential backoff retry mechanisms with circuit breakers to ensure eventual consistency is achieved once resources become available. |
| Don’t worry about handling those complex situations. Stacksaga provides the way that you can manage them easily. |
Here is the summarized diagram for compensating failed transaction.