Saga Client Server -

POST /payments/reserve (local transaction) Body: "orderId": "ord-1", "amount": 100 Response: "paymentId": "pay-1", "status": "reserved"

Client │ ▼ [API Gateway] │ ▼ [SAGA Orchestrator] ─────► [Order Service] ───► DB │ │ │ ▼ │ [Inventory Service] ───► DB │ │ │ ▼ │ [Payment Service] ───► DB │ └───► [SAGA State Store] (persistence) saga client server

If a step fails, the system executes "undo" actions (compensations) for every previously successful step to restore the system to a consistent state. Expose metrics: SAGA duration

Loose coupling, low latency. Cons: Complex logic, cyclic dependencies, hard to monitor. network) | Retry with backoff

Expose metrics: SAGA duration, step failures, compensation rate, active SAGAs.

To implement the Saga client-server architecture effectively, follow these best practices:

| Failure point | SAGA action | Client impact | |---------------|-------------|----------------| | Server A fails before committing | Retry or abort SAGA (no compensation needed) | Transient error | | Server B fails after Server A committed | Execute compensation in Server A | Client sees "compensated" status | | Orchestrator crashes mid-SAGA | Recover state from persistent log | Client may see delayed completion | | Compensation fails (e.g., network) | Retry with backoff, log for manual intervention | Status "COMPENSATION_FAILED" |