In a monolith, many operations can run inside one transaction: change several records, something fails, roll everything back.
In a microservice system, the same business process may span several independent services and databases. The order is created. Payment is captured. Stock is reserved. Delivery is not yet booked. Then one step fails.
There is no single transaction to roll back. The system has to decide what to do with actions that already happened. That is where Saga appears.
What problem are we solving?
A Saga splits a long business process into a sequence of local operations. Each service performs its part and reports the result.
If all steps succeed, the process completes. If one fails, compensating actions are started for operations that have already happened.
For example, if payment was captured but inventory cannot be reserved, the compensation may be a refund. That is not a technical database rollback. It is another business action.
What does the business get?
The business can run end-to-end processes across independent systems without merging them back into one technical monolith.
Teams can evolve payments, orders, logistics, or other domains separately while the company still presents one customer journey.
This becomes useful when parts of the process belong to different teams, scale differently, or even depend on external providers.
There is an organizational benefit too: exception handling becomes explicit. What happens if money is captured but the order is not created? How long do we wait for confirmation? When do we refund? Who owns a stuck operation?
Saga forces these questions to move from “rare incident” into the design of the business process itself.
What does the team get?
Teams keep local transactions inside their services and avoid one distributed transaction spanning the whole system.
A Saga may be coordinated by a central orchestrator or through events where services react to one another.
But engineering complexity grows. The system must track process state, handle duplicate messages, ensure idempotency, resume after failures, and show where a process stopped.
What does the customer get?
The customer can complete a complex journey across several systems as one product experience.
But intermediate states may become visible: “order processing,” “refund initiated,” “waiting for warehouse confirmation.” In a distributed system, every step does not have to become final instantly.
So customer experience depends not only on technical correctness but also on clear communication of process state.
What do we pay for it?
The biggest price is that compensation is not always the same as undo.
An email that was sent cannot be unsent. Physical delivery cannot be rolled back like a database row. A refund may itself take time or fail.
Every step needs consequences designed in advance, and some failed processes may require manual intervention.
The business also has to accept eventual consistency: for some period of time, different systems can show different stages of the same operation.
When is Saga unnecessary?
If the whole process lives in one application and one database, a normal transaction is usually simpler and more reliable.
Do not build a distributed workflow for architectural appearance. Saga makes sense when service boundaries already exist for other reasons and an end-to-end process must cross them.
Questions to ask before choosing it
- Which steps of the business process already live in different systems?
- How do we compensate each step if the next one fails?
- Which actions are irreversible or require manual handling?
- What intermediate state will the customer see?
- Who owns a process that gets stuck between services?
In the end
Saga lets systems remain independent while still participating in one business process.
The price of that independence is having to design not only the happy path, but exactly what the business does when the process stops halfway through.