Sagas: multi-step workflows without distributed transactions

Nothing rolls back across services: every undo is a new step, run last-first, and allowed to run twice.

Before you read: predict

A chat platform sells paid rooms. Its booking saga holds the room name #quiz-night, takes 5 € from the creator's card through billing, then asks for the room to be created. Each of the three services keeps its own database. The rooms service refuses: the creator's plan allows no more rooms, and it will refuse every retry.

Which handling leaves the creator's card statement netting 0 € and the name free for anyone?

The 30-second version

A saga runs one operation across services as a sequence of local transactions, each committed on its own. If a later step fails, the saga runs compensations for the steps already done, the last one first. A compensation is a new action others can see, such as a refund, so it must finish and be safe to repeat.

Nothing rolls back across services: every undo is a new step, run last-first, and allowed to run twice.

How it works

Step 1 of 14

No transaction spans the services. Each service commits to its own database; a rollback in one undoes only that one's rows. microservices.io

In the kitchen

each party's own books → each service's local transaction (steps 1–2)

Analogy: Entering a crew in an away regatta

The rowing club's secretary works through an entry checklist. A guesthouse holds rooms for the crew, a hire yard lends a boat trailer for a deposit, and the regatta's organisers take the entry fee, each in its own books. If the organisers refuse the entry, the deposit comes back as a refund that shows on both bank statements. The refund quotes the hire number, so a second request with that number pays nothing.

On the regatta trip	In the saga
each party's own books	each service's local transaction (steps 1–2)
a refund on both statements	a compensation, a new visible action (step 4)
unwinding from the trailer back to the rooms	compensations last step first (step 5)
the hire number on the refund	the saga's key on a compensation (step 8)
the secretary's checklist, phoning each party	orchestration (steps 11–12)
a chain where each party moves when told	choreography (steps 13–14)

In real terms: an undo is one more step in each participant's history, never an erased page.

Breaks down when: a secretary can ring everyone and ask them to wait, while a service cannot pause the others between steps.

Contrasting case: two tables in one database: one local transaction covers both, and a rollback really undoes them.

Examples, run for real

4.1 ExamHall: the paid re-sit booking

EXH-3950: booking a paid ECON-201 re-sit reserved seat 117 and charged the 40 € fee; the exam board then refused the ticket. The handler "rolled back" by deleting its own payment row. MR !4250 runs the booking's compensations instead: a refund under the key refund-<booking>, then the seat release.

4.1 EXH-3950 seat 117 held, 40 € charged, ticket refused · handler deletes its payment row · statement +40.00 (net +40.00) · payments table: none · seat held
4.1 MR !4250 same refusal · compensations run: refund 40 €, then release seat · statement +40.00 -40.00 (net +0.00) · payments table: charge, refund · seat free

Deleting the row changed ExamHall's books, not the card network's (steps 1, 4); the refund is a second line, and the seat goes back last-first (step 5).

4.2 Chat: a refused room, a failure event delivered twice

A choreographed paid-room saga: billing listens for RoomRefused and refunds. The broker delivers the event twice, as its first acknowledgement was lost; billing sends each refund under the key refund-<saga>.

4.2 RoomRefused delivered 2 times · billing refunds under refund-<saga> each time · refunds applied 1 · statement net +0.00

The second delivery ran the compensation again, and the key made it act once (step 8).

Try it

Answer first, then check. Nothing is saved.

Question 1 of 7

A paid-room saga reserved the name #book-club, charged the creator 5 € and created the room; then the public directory refused to list it, so the orchestrator compensates. Meanwhile, other creators keep trying to reserve names.

In which order should the orchestrator run the three compensations?

Question 2 of 7

In a mock interview you said that when the room create is refused, the saga refunds the creator's 5 €. The interviewer asks: "And if the refund call fails?" Then she adds: "The card provider answers 503 to every call for 10 minutes, and the reply to its first call after that is lost." The orchestrator tries once a minute.

Which answer leaves the creator's statement netting 0 € and the saga finished?

Question 3 of 7

The chat platform runs two sagas. The paid-room booking has three participants today; next quarter tax, moderation and search join it, and the roadmap names more after them. The room rename has two participants, names and rooms, and nobody plans a third.

Which pairing does the Azure Architecture Center's saga page favour?

Question 4 of 7

A teammate proposes a fix for the re-sit booking: when the exam board refuses the ticket, delete the payment row in the same handler. Write three sentences to the teammate: why that does not undo the charge, what the booking saga should do instead, and what must be true of that action if it runs twice.

What do you write to the teammate?

Your answer (optional, stays on this page)

Question 5 of 7

A paid live Q&A room needs four steps: reserve its name, charge the creator 5 €, book a human captioner from an outside agency for 30 € that the agency never refunds, and announce the room in the members' feed. The name can be taken, the card declined and the agency fully booked, each for good; the feed only ever fails briefly, so its post is retried until it goes out, and a post members have read cannot be taken back.

Which order means that, whichever step fails, no captioner is paid and no announcement is posted for a room that never opens?

Question 6 of 7

The paid-room booking is now orchestrated and has six participants. The orchestrator runs as one process with no standby. On Tuesday it is down for 20 minutes, while names, billing and rooms all stay up.

During those 20 minutes, what does the Azure saga page lead you to expect for bookings?

Question 7 of 7

A paid-room orchestrator asks the names service to reserve #quiz-night for saga s1. The request is held up in transit: the orchestrator's call times out after 10 s, and the request reaches the names service at t=90. At t=10 the orchestrator compensates. At t=120 another creator tries to reserve #quiz-night.

Which compensation lets that creator have the name?

Go deeper

Pro tip

Write each step's compensation before the step, and run the pair in a test. For every step, inject a failure into each later step and check the end state: money net, holds released, and a second delivery of the failure event changing nothing. When: designing any multi-service flow (steps 3–8). Verify.

Sources

Microsoft Azure Architecture Center, Saga distributed transactions pattern: https://learn.microsoft.com/en-us/azure/architecture/patterns/saga · azure-saga.txt. Named in the curriculum row. "If a step fails, a series of compensating transactions undoes the changes that the completed steps made."; "Pivot transactions serve as the point of no return in the saga."; "Retryable transactions follow the pivot transaction."; "Compensating transactions might not always succeed, which can leave the system in an inconsistent state."; "there's no built-in isolation across services"; the benefits and drawbacks of choreography and orchestration quoted at P3 and D1. Supports steps 2–3, 6–7, 10–14. Valid as of 2026-10-13.
Chris Richardson, microservices.io, Pattern: Saga: https://microservices.io/patterns/data/saga.html · microservices-io-saga.txt. Named in the curriculum row. "Lack of automatic rollback - a developer must design compensating transactions that explicitly undo changes made earlier in a saga rather than relying on the automatic rollback feature of ACID transactions"; "In order to be reliable, a service must atomically update its database and publish a message/event." Supports steps 1, 4 and the outbox link. Valid as of 2026-10-13.
Garcia-Molina and Salem, Sagas, SIGMOD 1987 (named in the row): the PDF at cs.cornell.edu answered 200 on 2026-10-13, but it is a scanned image with no text layer and no PDF text tool is installed from npm for this lesson, so no passage could be saved; it keys nothing.

Checked against the tools and docs as of 2026-10-13.

Predict first