The Saga pattern is useful whenever a single business process spans multiple microservices and each step must succeed or fail together, even though no distributed transaction is available.
Key Points: • It fits multi-step workflows like order processing, where separate services handle payment, inventory, and shipping. • It's valuable when partial failure is unacceptable business-wise, such as charging a customer without reserving the product they paid for. • Long-running business processes, where steps may take seconds or minutes to complete, benefit from Saga's asynchronous, event-driven coordination. • It's especially relevant once a monolith with a single database has been split into services that each own their own data. • It's less useful for simple, single-service operations that don't need cross-service coordination at all.
Example: In a travel booking system, a trip reservation touches Flight, Hotel, and Car Rental services; if the car rental fails after the flight and hotel succeeded, the Saga triggers compensating transactions to cancel the flight and hotel bookings so the customer isn't left with a partial, inconsistent reservation.
Interview Tip: A concise interview answer is:
"I'd reach for the Saga pattern any time a business process spans multiple services that each own their own data and the whole process needs to succeed or fail as a unit, like order or travel booking flows. It lets me coordinate through local transactions and compensating actions instead of needing a distributed transaction that microservices architectures don't really support."