Compensating Transaction
Compensating Transaction undoes completed steps of a distributed operation when a later step fails, using business-level reversals instead of distributed ACID rollback. It enables eventual consistency but requires carefully designed, idempotent compensations.
The Compensating Transaction pattern reverses the effects of completed steps when a later step in a multi-step operation fails. In distributed systems where a single ACID transaction across services is impractical, each step is committed independently, and consistency is restored by running compensating actions that semantically undo prior steps.
The problem is partial failure. An operation spanning several services or resources may complete some steps and then fail. Because the committed steps cannot be rolled back atomically, the system must actively counteract them.
How It Works
Each step in the workflow has a defined compensating action that reverses its business effect, for example refunding a payment, releasing reserved inventory, or canceling a booking. If the workflow fails at step N, the orchestrator runs compensations for steps N-1 down to 1 in reverse order.
Compensations are not always exact inverses; they restore consistency at the business level. Refunding a charge does not delete the original transaction record. Compensations should be idempotent and retryable, because they too can fail and must be re-driven. This is the core mechanism behind the Saga pattern.
When to Use It
Use it for long-running, distributed operations where two-phase commit is unavailable or too costly, and where eventual consistency is acceptable: order processing, travel bookings, and provisioning workflows that touch multiple services.
Avoid it when a single resource or a true distributed transaction can provide atomicity simply, or when no meaningful compensation exists for an action.
Trade-offs
Designing correct compensations is hard, especially when other operations have already observed the intermediate state. There is a consistency window during which the system is partially updated. Some effects cannot be fully undone (an email already sent), so compensation may mean a corrective follow-up rather than a clean reversal.
Compensation logic roughly doubles the workflow surface to build and test, and failures during compensation need their own handling.
Related Patterns
It is the failure-handling half of the Saga pattern. Sagas can be coordinated via Choreography (events) or orchestration. Retry helps both forward steps and compensations succeed despite transient errors.
Example
A trip-booking saga reserves a flight, then a hotel, then a car. The car reservation fails because no vehicles are available. The orchestrator runs compensations: cancel the hotel reservation and cancel the flight reservation, each idempotently. The customer ends up with no partial booking and no charge, and the system returns to a consistent state without ever holding a global lock across the three providers.