Saga Pattern

Sagas are implemented via two primary coordination styles. In Choreography, each service publishes events after completing its local transaction, and other services listen and react. In Orchestration, a central Saga Orchestrator (a stateful process) directs participants by sending commands. Orchestration centralizes logic and is easier to debug, while choreography is more decentralized and loosely coupled.

The core mechanism for rollback. Each step in a saga has a predefined compensating transaction that semantically undoes its effects. If step three fails, the saga executes the compensations for steps two and one in reverse order. These are business-level rollbacks (e.g., "Cancel Reservation," "Issue Refund") not database rollbacks, and must be idempotent to allow safe retries.

Sagas explicitly trade strong consistency for high availability and partition tolerance, aligning with the CAP theorem. The system is in an inconsistent state during saga execution but is guaranteed to reach a consistent final state—either the business transaction completes fully or all compensations succeed, returning the system to its initial consistent state. This is a form of eventual consistency.

Robust sagas require strategies to handle pervasive failures:

• Idempotent Operations: Every transaction and compensating transaction must be safely repeatable.
• Persistence: The saga's state and each participant's intent must be durably logged.
• Retry & Backoff: Failed steps use exponential backoff for retries.
• Dead Letter Queues (DLQs): Unrecoverable failures are moved to a DLQ for manual intervention, preventing system blockage.

Sagas differ fundamentally from ACID (Atomicity, Consistency, Isolation, Durability) database transactions:

• Atomicity: Achieved eventually via compensations, not instantly.
• Isolation: Typically absent; sagas can expose intermediate state to other transactions, requiring design for concurrency anomalies (e.g., using version numbers or pessimistic locks).
• Scope: ACID is within a single database; sagas manage transactions across heterogeneous, distributed services.

Sagas are often used in conjunction with other fault-tolerant patterns:

• Circuit Breaker: Prevents cascading failures when calling a persistently failing participant service.
• API Composition: The pattern for querying data across services, which sagas complement for writes.
• Event Sourcing: Sagas can be implemented as state machines where events represent state transitions, stored immutably.
• Outbox Pattern: Ensures reliable event publishing from a participant's local database transaction.

A stability design pattern that prevents a software component from repeatedly attempting an operation that is likely to fail. It monitors for failures and, when a threshold is exceeded, trips the circuit, causing all subsequent calls to fail immediately or be redirected to a fallback. This prevents cascading failures and allows the failing system time to recover.

• States: Closed (normal operation), Open (fast failure), Half-Open (probing for recovery).
• Key Use: Wrapping calls to external services, databases, or APIs that may become latent or unresponsive.
• Relation to Saga: Often used within a saga's local transaction step to prevent endless retries against a downed service, triggering the saga's compensating transaction instead.

An architectural pattern where the state of an application is determined by a sequence of immutable domain events, stored as the system of record. Instead of storing the current state, the system persists the events that led to that state. The current state is derived by replaying the event log.

• Core Benefit: Provides a complete audit trail and enables temporal querying ("what was the state at time X?").
• Relation to Saga: Sagas are often implemented using event sourcing. Each local transaction publishes an event, and the saga orchestrator or participants listen for these events to trigger the next step or a compensating action. This creates a durable, replayable record of the entire distributed transaction.

A pattern that separates the model for updating information (Commands) from the model for reading information (Queries). This allows each model to be optimized independently, scaled separately, and even use different database technologies.

• Command Side: Handles create, update, delete operations, often using Event Sourcing.
• Query Side: Handles read operations, using denormalized views optimized for specific queries.
• Relation to Saga: Sagas are inherently command-centric, coordinating state changes across services. CQRS is a complementary pattern often used within a service participating in a saga. The saga's commands update the service's state (command side), while the query side provides the eventually consistent views of that updated data.

A property of an operation whereby it can be applied multiple times without changing the result beyond the initial application. This is a critical design principle for safe retries in distributed systems where network calls can fail or duplicate.

• Key Implementation: Using unique request IDs (idempotency keys) that the server uses to deduplicate and return the same result for identical requests.
• Why it's Critical for Sagas: In a saga, a local transaction or a compensating transaction may be retried due to network timeouts. If these operations are not idempotent, a retry could lead to incorrect state (e.g., charging a customer twice, rolling back more than intended). Designing all saga steps to be idempotent is a fundamental requirement for correctness.

A resilience pattern inspired by ship bulkheads that isolate elements of an application into independent pools. If one pool fails ("floods"), the failure is contained, and the other pools continue to function. This prevents a single point of failure from cascading and taking down the entire system.

• Common Implementations: Using separate thread pools, connection pools, or even physical/virtual infrastructure for different client requests or downstream services.
• Relation to Saga: While a saga manages business transaction consistency, bulkheads manage resource isolation. They are used together: a saga's steps might call services that are themselves protected by bulkheads. For example, a failure in the payment service's thread pool won't affect the inventory service's ability to process other requests or participate in other sagas.

A business transaction that semantically undoes the effects of a previously committed transaction. Unlike a database rollback (which is technical and immediate), a compensating transaction is a business-level operation that may not perfectly restore the original state but brings the system to a consistent, acceptable state.

• Example: A RefundPayment transaction compensates for a prior ChargePayment transaction. The money is returned, but the audit log shows both events.
• Core of the Saga Pattern: Each step in a saga that updates data has a predefined compensating transaction. If a subsequent step fails, the saga executes these compensations in reverse order. The challenge is designing compensations that are feasible and correct from a business logic perspective.