In the previous subchapter, we saw event-driven architectures where a process is split into many independent steps. But this creates a delicate problem: what happens if a process has several steps and one of them fails halfway? For example, in an order, the payment is charged but then the stock reservation fails. You end up with a customer who has paid but has no product: an inconsistent state. The Saga pattern is the solution to coordinate multi-step processes that can fail, keeping everything consistent. We briefly mentioned it in subchapter 15.4; here we’ll look at it in depth.

In a monolithic system with a database, there’s a classic mechanism for this: transactions. A transaction says “either all steps are done, or none are”; if something fails halfway, everything is undone automatically (rollback) and it goes back to the initial state. It’s the “all or nothing” principle.

But in a microservices architecture (Chapter 17) or serverless (Chapter 28), each step is performed by a different service, each with its own database. There is no single transaction that covers them all. If step 3 of 5 fails, steps 1 and 2 have already been executed in other services and are not undone automatically:

You need a way to maintain consistency when an operation is spread across several services and something fails halfway. That’s what the Saga is for.

The Saga pattern manages an operation of multiple steps spread across services, so that if a step fails, the previous steps are undone through compensating actions (operations that cancel what has already been done). Instead of an “automatic rollback” (which doesn’t exist across services), you define how to undo each step, and the Saga executes them in reverse order if something fails.

Analogy: a Saga is like booking a vacation in parts (flight, hotel, and rental car, each on a different website). You book the flight ✓, you book the hotel ✓... and when you go to rent the car, there’s no availability ✗. Since you can’t go without a car, you have to cancel the previous bookings: you cancel the hotel (and get your money back) and cancel the flight. Each cancellation is a compensating action that undoes a booking. In the end, you’re back to the beginning, with no partial bookings. The Saga automates exactly that logic of “if something fails, undo the previous steps one by one.”

The essential difference from a traditional transaction: in a Saga, there is no automatic rollback. Instead, you explicitly define how to undo each step (its compensating action), and the Saga executes them when needed. This requires you to think, for each step, “how do I cancel this if something fails later?”

That’s why, when designing a Saga, for each action you also think of its opposite action: charge ↔ refund, reserve ↔ release, create ↔ delete.

There are two common ways to coordinate a Saga, connected to what you already know:

• By choreography (with events): each service reacts to events (event-driven style from subchapter 28.1) and, if something fails, emits a failure event that triggers compensations. There is no “director”; services coordinate with each other via events.
• By orchestration (with a coordinator): a central component directs the steps and, if one fails, orders the compensations. In AWS, the ideal tool for this is Step Functions, which we’ll see in the next subchapter (28.3): it allows you to define the flow of steps and what to do if each one fails, visually and in a controlled way.

• When you have a multi-step process spread across multiple services (microservices, serverless) and you need it to be consistent even if something fails halfway.
• Critical business processes like orders, payments, reservations, where leaving something “half-done” would be a serious problem.

⚠️ If your operation fits in a single service with a database, use a normal transaction (it’s simpler). The Saga is for when the operation crosses multiple services and no common transaction is possible.

Real-world example: a travel platform processes the booking of a complete package: flight, hotel, and transfer, each managed by a different service (sometimes from external providers). They implement a Saga: they book the flight, then the hotel, then the transfer. If in the last step the transfer is not available, the Saga executes the compensations: cancels the hotel and cancels the flight automatically, returning the customer to a clean state (no partial bookings or undue charges). The customer receives a “the booking could not be completed” message instead of being left with a flight and hotel but no way to get there. The Saga guarantees that the process is all or nothing, even though internally there are many independent services.

• In microservices/serverless, a multi-step operation is spread across multiple services without a common transaction; if a step fails halfway, the previous ones have already been executed and you end up with an inconsistent state.
• The Saga pattern manages these processes so that, if a step fails, the previous ones are undone through compensating actions (operations that cancel what has already been done), returning to a consistent state. Like canceling parts of a vacation booking if something doesn’t work out.
• The key: there is no automatic rollback as in a database; you define how to undo each step (charge↔refund, reserve↔release).
• It’s implemented by choreography (events, style 28.1) or by orchestration (a coordinator like Step Functions, subchap. 28.3).
• Use it for critical multi-service processes (orders, payments, reservations). ⚠️ If everything fits in a service with a database, use a normal transaction (simpler).

In the next subchapter, we’ll look at AWS’s ideal tool for orchestrating these multi-step flows visually and in a controlled way: Step Functions.