DataTerminology.comNEW
A distributed transaction pattern that coordinates a sequence of local transactions with compensating actions to maintain consistency.
DESCRIPTION
The Saga pattern breaks a long-running business process into a series of local transactions coordinated via events or a central orchestrator. If a step fails, compensating actions semantically undo prior work. Sagas avoid global locks and two-phase commit, improving availability and scalability. They embrace eventual consistency and require careful design of idempotent operations and failure handling. Orchestration centralizes control; choreography uses event-driven coordination. Observability is crucial for tracking state and diagnosing retries. Sagas are common in microservices and cloud-native applications.
ALTERNATIVE DEFINITIONS
microservices.io (Chris Richardson)
A saga is a sequence of local transactions where each step publishes an event that triggers the next step; compensating transactions undo work when failures occur.
Highlights event-driven coordination and compensating actions.
ACM (Original Sagas Paper)
Sagas are long-lived transactions that can be broken into a sequence of subtransactions, each with a compensating action in case of failure.
Original academic definition of sagas as long-lived transactions.
Microsoft Azure Architecture Center
The Saga pattern coordinates a series of local transactions to maintain data consistency across microservices without distributed transactions.
Emphasizes microservices consistency without 2PC.
RELATED TERMS
Compensating Transaction Orchestration Choreography Outbox Pattern Idempotency Eventual Consistency Message Broker Distributed Transactions Retries
COMPETING TERMS
KNOWLEDGE AREAS
Software Engineering Data Integration & Interoperability Real-time & Streaming Data Data Architecture
TARGET AUDIENCE
Software Developer Data Engineer DevOps Engineer Cloud Architect Data Architect MLOps Engineer
EXTERNAL SOURCES
- Wikipedia - Saga pattern
- Microsoft - Azure reference for saga pattern
- microservices.io - Overview and examples
- Red Hat - Guidance and patterns
TOP QUESTIONS
When should I use the Saga Pattern?
Use it when a business process spans multiple services and you need high availability without distributed transactions. It’s ideal for long-running workflows.
Category: Requirements
What’s the biggest misunderstanding about the Saga Pattern?
That it provides strong consistency like 2PC. Sagas typically deliver eventual consistency and require careful design of compensating actions.
Category: Misunderstanding
How is a saga orchestrated?
Either via a central orchestrator that commands steps or via choreography, where services react to events and progress the workflow.
Category: Example
What are common mistakes with Sagas?
Designing non-idempotent steps, weak compensations, or lacking observability can lead to duplicates and stuck workflows. Clear failure handling is essential.
Category: Mistakes
What is the main risk in applying the Saga Pattern?
Complexity in compensation logic and potential user-visible inconsistencies during convergence. Monitoring and retry policies mitigate these risks.
Category: Risks
How does Saga Pattern compare to Two-Phase Commit?
Sagas avoid global locks and coordinators, trading strict atomicity for availability and scalability. 2PC offers stronger consistency but can block.
Category: Alternatives
What is a good starting point to implement Sagas?
Begin by modeling each step and its compensation, ensure idempotency, and pick an orchestration or choreography approach supported by your messaging platform.
Category: Best practices
What’s a hot topic around Sagas today?
Using workflow engines and state machines to orchestrate Sagas with robust visibility, retries, and timeouts is increasingly popular.
Category: Topic
How do I test Sagas?
Simulate partial failures, retries, and compensations in integration tests. Use trace correlation to verify end-to-end behavior.
Category: Testing