In a Saga, if one step fails, data consistency is maintained by running compensating actions that logically undo the effects of previously completed steps, since there's no shared transaction to simply roll back.
Key Points: • Each service in the saga defines both a forward action (the normal operation) and a compensating action (how to undo it) in advance. • When a step fails, the saga triggers compensating actions for every previously successful step, in reverse order, to bring the overall process back to a consistent state. • Compensations are business-level undo operations, not database rollbacks — for example, "cancel booking" rather than reverting a raw SQL transaction. • Compensating actions must be idempotent and reliably executed, since they may need to be retried if a service is temporarily unavailable when the compensation is triggered. • This approach trades strict, immediate consistency for availability and service independence, accepting a brief window where the overall process is mid-compensation.
Example: In a travel booking saga covering flight, hotel, and car rental, if the car rental step fails after the flight and hotel were successfully booked, the saga triggers a "cancel flight" compensating action and a "cancel hotel" compensating action, returning the whole booking to an unbooked state.
Interview Tip: A concise interview answer is:
"When a saga step fails, I rely on predefined compensating actions for every previously completed step — for example, if a car rental booking fails after flight and hotel succeeded, I'd trigger cancellation events for both the flight and hotel to logically undo them. Since there's no shared transaction, consistency comes from these business-level compensations rather than a database rollback."