This pattern tries to solve a problem of a typical distributed system—transactional consistency.

A transaction could be defined as an action (or a series of coordinated actions) performed to fulfill a business functionality. This pattern tries to solve one of the problems of a typical distributed system—transactional consistency. In a distributed system (such as a cloud-based architecture), it's always very difficult to guarantee the consistency of a long-running transaction, so the idea of this pattern is to use a series of smaller individual transactions that can be undone (compensating transactions). In the Compensating Transaction pattern, the steps of a compensating transaction must undo the steps in the original operation.

In a cloud-based architecture, a transaction is not like a transaction on a database. When working with a database such as a SQL Server, if a transaction fails you can roll back the transaction to the original state. In a distributed cloud system, during a transaction of an instance of an application, other concurrent instances can change data, or if your transaction works on different cloud services, restoring the original state might not be so easy.

Imagine, for example, an application that calls a cloud service by passing data for validation, then updates an entity on a cloud database and after that, it sends a message to a queue. If one of these steps fail, the final business results could be affected.

As a definition, compensation is the process of restoring a system to its original state upon the occurrence of an error or a situation where the business transaction could not successfully proceed. The idea under the Compensating Transaction pattern is essentially this—when an operation starts, the application needs to record every step of the performed operation (if it was a success or not) and the steps to undo the work. When the transaction fails, the application can reverse the work by going back to each step and restoring the transaction to the original state.

This pattern should be used only when you have actions that must be undone (rolled back) if they fail.

An interesting C# implementation of this pattern can be found at this link: https://github.com/flowing/flowing-trip-booking-saga-c-sharp.

In my experience, using Azure Service Bus for handling the transaction compensation instead of implementing a workflow could be a valid approach. For each step of a transaction:

• The application sends a message to an Azure Service Bus with the transaction data and operation details
• The application performs the operation on the target service
• If the transaction step fails, the application can check the Azure Service Bus for restoring the entire transaction to the original state