Saga Pattern

TL;DR

Explanation

Distributed transactions across microservices can't use 2PC (too slow, too coupled). Saga: a sequence of local transactions (T1, T2, ..., Tn) where each Ti publishes an event triggering Ti+1. On failure at Ti: run compensating transactions (C(i-1), ..., C1) to undo. Two styles: choreography (each service publishes events and other services react — no central coordinator) and orchestration (a Saga orchestrator sends commands to services and handles failures centrally). Choreography: decoupled but hard to trace. Orchestration: easier to monitor and debug. PHP: Symfony Messenger workflows, custom saga state machine.

Common Misconception

Why It Matters

Common Mistakes

• No compensating transactions defined — partial failures leave data inconsistent.
• Choreography without correlation ID — impossible to trace saga execution.
• Not handling compensating transaction failures — need retry + alerting.

Code Examples

// 2PC across services — tight coupling, deadlock risk:
$coordinator->prepare('order-service', $orderTx);
$coordinator->prepare('payment-service', $paymentTx);
$coordinator->commit(); // Both or neither

// Saga orchestration:
// 1. OrderService.createOrder() → publishes OrderCreated
// 2. PaymentService.processPayment() → publishes PaymentProcessed
// 3. InventoryService.reserveItems() → publishes ItemsReserved
// On PaymentFailed: publish OrderCancelled → inventory released

$sagaState = ['order_id' => $orderId, 'step' => 'payment', 'status' => 'pending'];
// Orchestrator retries failed steps, triggers compensations on unrecoverable failure

References

• ↗ https://microservices.io/patterns/data/saga.html

Tags

Related Terms