Saga Pattern

In this decentralized coordination style, each local transaction publishes an event upon completion. Subsequent saga participants listen for these events and trigger their own local transactions. There is no central coordinator.

• Pros: Simple, loosely coupled, and does not create a single point of failure.
• Cons: Can become difficult to understand and debug as the saga logic is distributed across services.
• Example: An OrderCreated event triggers an InventoryReserved event, which then triggers a PaymentProcessed event.

This centralized approach uses a saga orchestrator—a dedicated service that executes the saga by issuing commands to participants and managing the overall flow and error handling.

• Pros: Centralized control, easier to understand, and simplifies complex business logic and rollback procedures.
• Cons: Introduces a potential single point of failure in the orchestrator and adds coupling between the orchestrator and participants.
• Example: An OrderSagaOrchestrator service explicitly calls the InventoryService, then the PaymentService, and manages compensation if any step fails.

The core mechanism for achieving rollback in a saga. For every forward operation in the sequence, a corresponding compensating transaction is defined to semantically undo its effects when a failure occurs later in the saga.

• Key Principle: Compensations are business-level rollbacks, not database rollbacks. They may involve issuing a refund, releasing reserved inventory, or sending a cancellation notification.
• Idempotence: Compensating actions must be idempotent to handle retries safely.
• Example: The forward transaction ReserveInventory(item_id, quantity) is compensated by ReleaseInventory(item_id, quantity).

Sagas explicitly trade strong consistency for availability and partition tolerance, aligning with the CAP Theorem. The system guarantees that all services will eventually reach a consistent state, but temporary inconsistencies are allowed during the saga's execution.

• Business Context: This model is suitable for business processes that can tolerate short-term inconsistencies (e.g., an order being 'processing' while payment is pending).
• Contrast with 2PC: Unlike Two-Phase Commit (2PC), which uses locks for strong consistency, sagas avoid long-lived locks, improving scalability and resilience.

Critical implementation details for ensuring reliability:

• Saga Log: A persistent store that records every step (command sent, event received, compensation triggered) in the saga's execution. This is essential for recoverability after a crash, allowing the orchestrator or participants to rebuild their state.
• Idempotent Operations: All participant services must implement idempotent handlers for commands and compensations. This ensures that retrying a message (due to timeouts or network issues) does not cause duplicate side effects. A common technique is using a unique idempotency key per saga step.

Sagas must handle several failure scenarios gracefully:

• Business Logic Failure: A participant fails its business validation (e.g., insufficient funds). The saga executes backward recovery, triggering all compensations for completed steps in reverse order.
• Technical Failure: A service or network is unavailable. The system employs retries with exponential backoff. If retries are exhausted, the saga is paused and can be resumed or manually intervened based on the saga log.
• Timeout Management: Each step requires a timeout. Expired timeouts trigger compensation, preventing the saga from hanging indefinitely.

A distributed atomic commitment protocol that ensures all participants in a transaction either commit or abort. It uses a coordinator to manage two phases:

• Prepare Phase: The coordinator asks all participants if they can commit.
• Commit/Abort Phase: If all participants vote yes, the coordinator instructs them to commit; otherwise, it instructs an abort.

Key Difference from Saga: 2PC is a blocking, synchronous protocol that locks resources for the duration, making it less suitable for long-running transactions. Sagas use asynchronous, compensating transactions for rollback.

An architectural pattern where the state of an application is determined by a sequence of immutable events, stored as the system's source of truth. The current state is derived by replaying these events.

Relation to Saga: Sagas are often implemented using Event Sourcing. Each local transaction within a saga publishes an event (e.g., OrderCreated, PaymentProcessed). The saga orchestrator listens to these events to trigger the next step or a compensating action, making the entire long-running transaction's progress observable and replayable.

A transaction explicitly designed to semantically undo the effects of a previous committed transaction. It is a core building block of the Saga Pattern.

Characteristics:

• Not a simple database rollback: The original transaction is already committed; the compensator executes new business logic (e.g., RefundPayment, RestoreInventory).
• Idempotent: Must be safely retryable in case of failures during the compensation phase.
• May not fully reverse state: In complex systems, a compensation might leave the system in a semantically correct, but not identical, state (e.g., a canceled flight booking results in a credit, not an identical seat).

The two primary coordination styles for implementing the Saga Pattern.

Choreography:

• Decentralized control. Each local transaction publishes an event. Other services listen and react.
• Pros: Loose coupling, simple.
• Cons: Can become difficult to understand as complexity grows; cyclic dependencies are possible.

Orchestration:

• Centralized control. A dedicated saga orchestrator (stateful) sends commands to participants and manages the sequence and compensation logic.
• Pros: Clear workflow definition, easier to manage complex dependencies, central point for monitoring.
• Cons: Introduces a potential single point of failure (mitigated by making the orchestrator itself resilient).

A consistency model for distributed data stores that guarantees: if no new updates are made to a given data item, all accesses will eventually return the last updated value.

Relation to Saga: The Saga Pattern is a tool for managing consistency in an eventually consistent system. During the execution of a saga, the system is in an inconsistent intermediate state (e.g., inventory is deducted but payment is not yet processed). The saga's completion (or compensation) moves the system toward a new, eventually consistent state. Sagas provide a business-process-level framework for this journey.

An operation that can be applied multiple times without changing the result beyond the initial application. This is a critical requirement for both saga participant transactions and compensating transactions.

Why it's Essential for Sagas: Network failures or timeouts can cause commands/events to be retried. If a DebitAccount command is received twice, it must not debit the account twice. Techniques to achieve idempotency include:

• Using a unique idempotency key with each request.
• Having participants check if a request with a given ID has already been processed.
• Designing operations to be naturally idempotent (e.g., SetStatus('paid')).