Some business workflows are too long, and touch too many services, to run as one big database transaction. No service can roll back another service's committed work. The Saga pattern is the usual answer: it breaks a long workflow into a sequence of local transactions across services.

Each step commits in one service. If a later step fails, the saga runs follow-up actions to repair the steps that already completed. For example, an order workflow might create an order, reserve inventory, and charge a customer. If payment fails, the saga releases the reservation and cancels the order.

A saga is not a distributed ACID transaction. It does not hide every temporary state, and it does not make all services commit or roll back together. Instead, it gives the system a clear path to reach a correct business outcome over time.

This chapter explains how sagas coordinate steps, how compensation works, and when sagas are the right trade-off.