Persist which steps completed and the business information needed to undo or offset them.
Reliability & Delivery · Distributed Consistency
Compensating Transaction
Record enough business context to execute compensating actions for completed steps. Compensation restores a valid state rather than attempting an impossible distributed rollback.
How can completed work be undone when a distributed operation fails after some steps have already succeeded?GateSift summary based on Microsoft Azure Architecture Center guidance. The wording, visualization, Azure mapping and analyzer context are original GateSift material.
Original GateSift visualization
How Compensating Transaction works
Completed business steps are reversed or neutralized through explicit compensating actions.
Partially completed work
Compensate
Valid restored state
Run compensating actions in a safe order when the overall operation cannot complete.
Record compensation outcomes and escalate any compensation that also fails.
Curated GateSift guidance
When this pattern is a good fit — and when it is not
Use a compensating transaction when previously completed work cannot be rolled back technically, but a later business action can restore an acceptable outcome after partial failure.
- Earlier steps have already committed and a later failure requires business-level recovery.
- The system can record enough information to construct the compensating action later.
- Compensation may need to occur in a different order from the original operations.
- A normal local rollback can still undo the complete unit of work safely.
- No business operation exists that can neutralize or correct the completed side effect.
- Compensation would destroy legitimate concurrent changes made after the original action.
Compensation is not rollbackReview
The final state may be business-equivalent rather than byte-for-byte identical to the original state.
Concurrent change conflictHigh impact
Blind reversal can overwrite valid work that happened after the original step completed.
Failed compensationHigh impact
Recovery actions require their own retry, observability and escalation strategy.
- Persist the data needed to compensate at the time the forward action succeeds; do not assume it can be reconstructed later.
- Use explicit workflow states for compensation pending, running, completed and failed so support teams can see recovery progress.
- Make compensating commands idempotent because a timeout can leave their completion uncertain just like the original action.
What this pattern helps you decide
Record enough business context to execute compensating actions for completed steps. Compensation restores a valid state rather than attempting an impossible distributed rollback.
What exact business outcome does compensation restore?
Which data must be captured when the forward operation succeeds?
How does compensation avoid overwriting legitimate changes that happened afterward?
Where you may see it
- Logic App catch scopes that invoke compensating actions
- Durable Functions orchestration compensation
- Service Bus commands that reverse earlier business operations
How the analyzers can surface it
- Multi-step workflows with side effects but no compensation path
- Catch scopes that only log and terminate after partial writes
- BizTalk orchestrations with compensation blocks or long-running transactions
Pattern detection is contextual. GateSift should present these as architectural signals, not claim a pattern is implemented solely because one policy statement or adapter exists.
Source guidance and attribution
This page links to Microsoft Azure Architecture Center for the source architecture guidance. GateSift summaries, diagrams, Azure examples and analyzer signals are original. No endorsement by Microsoft is implied.