resilienceestablished · high operational burden

Compensating Actions

Also known as: compensation, undo-steps, semantic-rollback

Intent

Undo the effects of completed steps in a multi-step process by running explicit inverse operations when a later step fails.

Problem

A business process spanning several services cannot use a single ACID transaction, and some steps cannot be rolled back by the database. If step three fails, steps one and two have already committed and visible effects exist.

Forces

•No distributed transaction is available
•Intermediate states are visible to others
•Some effects cannot be reversed exactly
•Compensations can themselves fail

Solution

Overview

Compensating actions are the rollback mechanism of the saga approach. Instead of preventing partial results, the system repairs them by performing business-level inverses.

How it works

Each forward step is paired with a compensation, and a coordinator or choreography tracks progress.

1 reserve inventory    <-> release inventory
2 charge card          <-> refund payment
3 create shipment      <-> cancel shipment

step 3 fails -> run 2's refund, then 1's release

The saga state is stored durably, for example in a table or workflow engine such as Temporal or Step Functions, so recovery continues after a crash. Compensations run in reverse order, are retried with backoff, and carry idempotency keys. Where the world cannot be restored exactly, such as an email already sent, the compensation sends a correction instead.

Pitfalls

A compensation is not a true rollback. Other readers may have seen the intermediate state, so design for semantic locks or pending statuses.
Without idempotency, retried compensations double-refund or double-release.
Order dependencies matter, since cancelling a shipment before refunding may be required.
Some steps are pivots that cannot be undone, so place them last or make them retriable until success.
Failed compensations need alerting and a manual resolution path.

Key takeaways

Define the inverse of every side-effecting step.
Persist saga state and make every action idempotent.
Order irreversible steps last.
Plan for compensations that fail.
Log every compensation with the saga identifier so support teams can reconstruct what happened to a customer order after a partial failure.

✓ When to Use

•Sagas across microservices
•Order, booking, and payment workflows
•Long-running business transactions

✗ When Not to Use

•Single database where a real transaction works
•Irreversible effects with no acceptable correction
•Strict isolation requirements for intermediate state

Pros

+Works without distributed transactions
+Service autonomy preserved
+Matches how business processes handle errors

Cons

−Temporary inconsistency is visible
−Compensation logic must be designed per step
−Failure of compensation needs handling

Cost Profile

Infrastructure

Low, uses existing services

Operational

Medium to high, monitor stuck sagas

Cognitive

High, reasoning about partial states

Failure Modes

Compensation fails repeatedly and leaves the process half-undone
Non-idempotent compensation runs twice, such as double refund
Other users act on intermediate state before it is undone

Real-World Examples

Alternatives

Related Patterns

retry-with-backoff

Competency Domains

data statedistribution communication