The Saga pattern addresses data consistency across microservices by breaking a business transaction into a sequence of local transactions, each owned by a different service, with compensating actions to undo prior steps if a later one fails.
Key Points: • Each service performs its own local transaction and then publishes an event or message signaling completion, which triggers the next step. • If any step fails, previously completed steps are undone using compensating transactions rather than a database rollback, since there's no shared transaction to roll back. • Choreography-based sagas coordinate through events with no central controller; orchestration-based sagas use a dedicated coordinator service to direct each step. • This approach avoids the need for a distributed two-phase commit, which doesn't scale well and reduces availability in a microservices architecture. • Idempotency is important — since messages can be redelivered, each step and compensation must be safe to apply more than once.
Example: In a travel booking saga, if the Flight and Hotel services succeed but the Car Rental service fails, compensating events are sent to cancel the already-confirmed flight and hotel bookings, returning the overall booking to a consistent "not booked" state.
Interview Tip: A concise interview answer is:
"I use the Saga pattern — each service does its local transaction and emits an event, and if a later step fails, compensating transactions undo the earlier steps rather than relying on a distributed transaction. It keeps services independent while still giving the overall business process consistency, at the cost of needing to design compensating actions for every step up front."