The Saga and the Undo Step

Module 5 of 8 in the chapter Integration Orchestration, chapter 15 of the Integration Architect course. Each module stands on its own. Previous: Orchestration or Choreography · Next: Where the Conductor Lives

The question this module answers: When a chain of steps across systems fails partway through, how do you take back the steps that already happened?

A Chain of Steps, Each on Its Own

Back to module 1’s order, the one the middleware coordinates. It checks the customer’s balance, submits the order to the ERP, then updates inventory. Module 3 showed why nothing rolls those back automatically: each system commits its own step the moment it finishes.

So what happens when inventory fails, after the ERP already has the order? You need a way to take the order back. Not a rollback, because there isn’t one across systems. A new step, designed to undo the one before.

That design has a name: the saga. Chris Richardson’s pattern catalog defines it: “A saga is a reliably coordinated sequence of local transactions.” Each step is an ordinary, local piece of work in one system. And when a step fails, “the changes made by the completed steps are undone by compensating transactions.”

The catalog’s own example is almost exactly the one I use in class: an order that mustn’t go over the customer’s credit limit, created “in a PENDING state” until the credit check comes back. Module 3’s in-between state, in the textbook.

Every Step Has an Undo

The undo step is called a compensating transaction. It doesn’t erase the step it undoes. It does something new that cancels its effect.

• The ERP accepted the order → cancel the order in the ERP.
• Stock was reserved → release the stock.
• A card was charged → refund it.

Notice what that means. The cancelled order still exists in the ERP, marked cancelled. The refund is a second transaction, not a missing first one. Anyone looking later can see what happened and what was undone. That’s often what auditors want anyway.

And nobody gives you these for free. The pattern catalog lists it first among the saga’s drawbacks: “Lack of automatic rollback - a developer must design compensating transactions that explicitly undo changes made earlier in a saga.” For every step, someone has to ask: what’s the undo, which system does it, and does that system even offer it? If the ERP has no way to cancel an order through its API, that’s a requirement to find in week one, not on go-live day.

Click to enlarge

Undo what already happened, in reverse.

Some Steps Can’t Be Undone

Some things can’t be called back. An email has been read. A truck has left the yard. A payment to a supplier has gone. There’s no compensating transaction for those, only an apology.

So the order of the steps is a design decision, and the rule is simple: the steps you can’t take back go as late as possible. Reserve before you charge. Charge before you ship. Send the “your order is confirmed” message only when everything else has succeeded.

Microsoft’s architecture guide names the moment that matters: the pivot. “Pivot transactions serve as the point of no return in the saga. After a pivot transaction succeeds, compensable transactions are no longer relevant.” Before the pivot, every step can be undone. After it, you don’t go back: you go forward. And the steps after the pivot are built to finish: “Retryable transactions are idempotent and help ensure that the saga can reach its final state, even if temporary failures occur.”

So a well-designed saga has three parts, in order:

1. Steps you can undo, each with its compensating step.
2. The pivot, the point of no return.
3. Steps that must finish, retried until they do, and safe to repeat.

Click to enlarge

Undoable first, the point of no return, then steps that must finish.

The Undo Can Fail Too

Here’s the uncomfortable part. The undo step is a call to another system, and calls fail. Microsoft’s guide says it directly: “Failure-handling logic, such as compensating transactions, is also prone to failures.” You try to cancel the order in the ERP, and the ERP is down. Now what?

The same tools as any other step, from chapter 14:

• Make the undo safe to repeat. “Cancel order 1042” should be fine to send twice; cancelling an order that’s already cancelled changes nothing. That way, the undo can be retried without fear (chapter 14 module 4).
• Retry it, and when retries run out, hand it to a person. A failed undo goes to the to-do list, with the owner alerted (chapter 14 module 6). A failed undo is one of the most important failures you’ll ever log, because the systems now disagree and nothing will fix it on its own.
• Keep the status honest. While the undo is pending, the record says so: not Pending, not Rejected, but Undo in progress. Module 3’s states, one more of them.

Who Runs the Saga

Module 4’s choice applies here too. A saga can be orchestrated: a conductor calls each step, and on a failure calls each undo in reverse. Microsoft’s guide: “The orchestrator performs saga requests, stores and interprets the states of each task, and handles failure recovery by using compensating transactions.” Or it can be choreographed: each system reacts to the last one’s event, and a failure event sets off each system’s own undo.

For a saga, I’d lean towards a conductor more often than not. A saga’s whole job is to know which steps have happened, so that it can undo the right ones, and that’s exactly what a conductor keeps. In choreography, every system has to work out for itself whether it needs to undo, from events that may arrive late or twice. It can be done, carefully. Module 6 looks at where the conductor can live.

A Labelled Example: Steve Trucking’s Paid Redelivery

Here’s how it would look for Steve Trucking, as a “what if” that isn’t in the scenario. Say a recipient misses a delivery, and the partner asks for a paid redelivery. Three systems take part:

1. Book a redelivery slot on the crews’ schedule in Salesforce. Undo: release the slot.
2. Add a charge line for the partner in the finance ERP, which already invoices the partners. Undo: a credit line that cancels it. This is the pivot: once the charge is accepted, the redelivery goes ahead.
3. Send the recipient the day-before message through the SMS and email provider. No undo: a message can’t be unsent. So it goes last, and it’s retried until it’s delivered.

If the ERP refuses the charge, the saga releases the slot and stops, and the recipient was never told anything they’d have to unlearn.

Test knowledge. Know how to handle a failure partway through a process that spans systems: there’s no rollback across them, so each completed step is undone with its own compensating step (cancel, release, refund), in reverse order, and steps that can’t be undone come last. Know that the undo must be safe to retry.

Beyond the exam: what AI changes. An agent that books, charges and notifies across three systems is running a saga, whether or not anyone designed it as one. If it fails halfway, does it know which steps to undo, and does each system give it a way to? Give an agent the same three things you’d give a conductor: an undo for every step it can take back, a clear point of no return, and a person to hand it to when the undo fails.

What an Architect Decides Here

• For every step in a chain across systems: its undo, which system performs it, and whether that system offers it.
• The order of the steps: undoable first, the point of no return, then the steps that must finish.
• What happens when an undo fails: safe to repeat, retried, then a person, with the status saying so.
• Who runs the saga: a conductor, or careful choreography.

Explore

• microservices.io, Pattern: Saga (opens in a new tab) (checked 2026-11-07).
• Microsoft Learn, Azure Architecture Center, Saga design pattern (opens in a new tab): compensable, pivot and retryable steps (checked 2026-11-07).
• There’s No Rollback Across Systems: module 3, the state in between.