The saga pattern is a way to coordinate a business process that runs across several separate services, where no single database can guarantee the whole thing succeeds or fails as one unit. Instead, the process is split into steps, and each step has a matching undo action in case a later step goes wrong.
Picture booking a holiday: flight, hotel and car, each from a different company. You cannot reserve all three in one atomic action. So you book the flight, then the hotel, then the car, and if the car falls through, you cancel the hotel and the flight to get back to a clean state. That cancellation is the ‘compensating action’, and stringing these steps and undos together is the saga. It is a common design pattern in systems built from microservices, often driven by messages on a queue.
There are two ways to run one. In choreography, each service reacts to events and triggers the next step on its own. In orchestration, a central coordinator calls each service in turn and handles the undos. Choreography is lighter; orchestration is easier to follow when the flow gets long.
One practical caveat: because steps and retries can repeat, each action needs to be safe to run twice, which is where idempotency comes in. The trade-off is real complexity. A saga only earns its keep when a process genuinely spans services; inside one service and one database, a plain transaction is simpler and safer.
At TopDevs we reach for the saga pattern only when a process truly crosses service boundaries, so reliability is gained without piling on complexity you do not need.
