Saga pattern for distributed transactions

A business operation spans multiple services (e.g., create order + charge payment + update inventory). If payment fails after order is created, the system is in an inconsistent state. Cannot use traditional database transactions across services.

Use the Saga pattern — a sequence of local transactions with compensating actions. Two approaches: (1) Choreography: each service listens for events and triggers the next step. Simple but hard to track. (2) Orchestration: a central coordinator manages the saga steps and compensations. More complex but clearer control flow. For each step, define a compensating action (undo): create order -> cancel order, charge payment -> refund, reserve inventory -> release. On failure: execute compensations in reverse order. Use idempotent operations — sagas may retry steps.

Distributed systems cannot use ACID transactions across service boundaries. The Saga pattern provides eventual consistency by decomposing a transaction into steps with compensating actions for rollback.