Saga Pattern

Overview

Overview The Saga pattern manages data consistency across microservices without distributed transactions. In a monolith, you wrap multiple database operations in a single ACID transaction. In microservices, each service owns its own database, so a single cross-service transaction is impossible without two-phase commit (2PC), which is slow, fragile, and locks resources.

A saga is a sequence of local transactions where each step is a transaction within a single service. If a step fails, the saga executes compensating transactions to undo the changes made by preceding steps. Think of it as "undo" rather than "rollback" — compensation is a new forward action, not a database rollback.

This pattern is critical in e-commerce (order creation spans Inventory, Payment, and Shipping services), banking (money transfers), and travel booking (flights, hotels, car rentals). Interviewers expect you to compare choreography and orchestration, design compensating transactions, and handle partial failure scenarios.

Key concepts

• Choreography-based sagas
• Orchestration-based sagas
• Compensating transactions
• Semantic locks and countermeasures
• Idempotency in saga steps
• Failure handling and partial rollback
• Saga execution coordinator (SEC)
• Event sourcing integration

Interview questions

• Compare choreography-based and orchestration-based sagas with a concrete example.
• How do compensating transactions work? Design compensation for an e-commerce order saga.
• What are semantic locks and other saga countermeasures?
• How do you handle saga step timeouts and the "stuck saga" problem?

More Microservices topics

• Bulkhead Pattern
• Circuit Breaker Pattern
• Configuration Externalization
• CQRS
• Event-Driven Architecture
• Retry Pattern
• Service Discovery
• Sidecar Pattern
• Strangler Fig Pattern