Saga Orchestration Pattern

Overview

Saga Orchestration is a design pattern for managing distributed transactions across multiple microservices. A central Orchestrator coordinates the entire transaction by issuing commands to participant services in a defined sequence and handling failures through compensating transactions executed in reverse order.

Traditional two-phase commit (2PC) does not work well over HTTP-based microservices due to latency, partial failures, and tight coupling. The Saga pattern breaks a distributed transaction into a series of local transactions, each owned by a single service. Orchestration places the coordination logic in one dedicated component -- the Orchestrator -- which knows the full workflow and drives each step forward or backward.

This pattern is the foundation of several production workflow engines:

• Temporal -- Durable execution platform for microservice orchestration
• Netflix Conductor -- Workflow orchestration engine for microservices
• Uber Cadence -- Fault-tolerant stateful workflow framework
• AWS Step Functions -- Serverless workflow coordination service
• Camunda -- Process orchestration for enterprise workflows

Architecture

Saga Orchestrator

The central coordinator that manages the lifecycle of a saga. It maintains a Saga Log to track which steps have been executed and their outcomes. On failure, it reads the log to determine which compensating transactions must run and in what order.

Participant Services

Each microservice owns a local transaction and its corresponding compensating action:

Saga Log

A persistent record of every step in the saga. The Orchestrator writes to the log before and after each step, enabling recovery after crashes. If the Orchestrator restarts, it can resume or compensate from the last recorded state.

Communication Model

The Orchestrator communicates with services via synchronous HTTP commands (request/reply). Each service performs its local transaction against its own database and reports success or failure back to the Orchestrator.

Key Concepts

Command-Driven Coordination

Unlike choreography where services react to events, orchestration uses explicit commands. The Orchestrator sends a command (e.g., ChargePayment) and waits for a response. This makes the flow deterministic and easy to reason about.

Compensating Transactions

Every forward step must have a corresponding compensating action that semantically undoes the work. Compensations are not rollbacks -- they are new transactions that reverse the business effect. For example, a payment refund is a new transaction, not an undo of the original charge.

Reverse-Order Compensation

When a step fails, the Orchestrator executes compensations in reverse order for all previously completed steps. If step 3 fails, it compensates step 2 first, then step 1. This preserves referential integrity between services.

Idempotency

All commands and compensations must be idempotent. Network failures can cause retries, and the Orchestrator may re-send commands. Services must handle duplicate requests gracefully, typically by checking saga/step IDs before executing.

Central Visibility

The Orchestrator and its Saga Log provide a single place to observe the state of any transaction. Operators can query the log to see which step a saga is on, whether it succeeded or is compensating, and which services have been contacted.

When to Use

Saga Orchestration is well-suited for:

• Complex multi-step workflows with many participant services (4+ steps)
• Workflows requiring central monitoring and operational visibility
• Strict ordering requirements where steps must execute in a specific sequence
• Scenarios with complex compensation logic that depends on which combination of steps succeeded

Consider Saga Choreography instead when:

• The workflow is simple (2-3 services)
• You want to avoid a single point of failure
• Services are loosely coupled and independently deployable
• Teams own their services end-to-end and prefer decentralized control

Scenarios

1. Happy Path -- All saga steps succeed: order created, payment charged, inventory reserved, shipping scheduled. The Orchestrator walks through all four steps sequentially and marks the saga as complete.
2. Payment Failure -- Order is created successfully, but payment fails due to insufficient funds. The Orchestrator compensates by cancelling the order (reverse of step 1) and reports the failure to the client.
3. Inventory Failure -- Order and payment succeed, but inventory reservation fails due to insufficient stock. The Orchestrator compensates in reverse order: refund payment (reverse of step 2), then cancel order (reverse of step 1). This demonstrates the cost of late failures -- more steps require more compensations.