🧾SAGA Pattern

Manage distributed transactions through local steps and compensating actions.

📌 Key IdeaSAGA breaks one cross-service transaction into ordered local transactions. If a later step fails, compensating actions undo earlier steps logically. This avoids 2PC bottlenecks but requires idempotency, retries, and careful failure design.

🧩

Problem it solves

Cross-service business flows cannot rely on one global ACID transaction safely.
2PC/distributed locking can reduce availability and increase coupling.
SAGA coordinates local transactions with compensations for recoverable distributed workflows.

📖

Definition

SAGA is a pattern for long-running distributed workflows. Each service commits its own local transaction and emits an event/command for the next step; failures trigger compensating steps.

✨

Why It Matters

Microservices cannot safely rely on one global ACID transaction.
Improves availability compared to distributed locking/2PC.
Explicit failure handling keeps business process recoverable.

💻

Code Variations

1️⃣ E-commerce order SAGAtext

Step 1: OrderService -> create PENDING order
Step 2: PaymentService -> reserve funds
Step 3: InventoryService -> reserve stock
Step 4: ShippingService -> create shipment

If Step 3 fails:
  compensate Step 2 (refund/release funds)
  compensate Step 1 (mark order CANCELLED)

2️⃣ Orchestrator-style pseudo workflowjava

public void placeOrder(OrderCommand cmd) {
  order.createPending(cmd.orderId());
  if (!payment.reserve(cmd.orderId(), cmd.amount())) {
    order.markFailed(cmd.orderId());
    return;
  }
  if (!inventory.reserve(cmd.orderId(), cmd.items())) {
    payment.release(cmd.orderId()); // compensation
    order.markFailed(cmd.orderId());
    return;
  }
  order.markConfirmed(cmd.orderId());
}

Each step and compensation must be idempotent.

📊

Choreography vs Orchestration

Aspect	Choreography SAGA	Orchestration SAGA
Control flow	Event-driven between services	Central orchestrator coordinates steps
Coupling shape	Implicit via events	Explicit via orchestrator logic
Observability	Harder end-to-end trace	Easier process visibility
Best fit	Smaller/simple domain flows	Complex flows with many branches/retries

🔀

Common Confusions Cleared Up

SAGA gives eventual consistency, not instant consistency

There are temporary intermediate states (PENDING, RESERVATION_IN_PROGRESS). UI and downstream services must tolerate this.

Compensation is not always strict rollback

Real-world compensation is business undo (refund/cancel/reverse), not always exact technical rollback.

⚠️

Common Mistakes / Anti-Patterns

No idempotency keys for commands/events.
Compensations missing for some failure branches.
Treating SAGA as exactly-once execution.
No timeout/escalation for stuck workflow steps.

🎤

Interview Q&A

🧾

Quick Cheat Sheet

GoalDistributed transaction without global lock/2PC.

Core toolsLocal transactions, events/commands, compensations.

Consistency modelEventual consistency.

Must-haveIdempotency + retries + traceability.

🔗