Saga Pattern 2D: Distributed Transactions Across Microservices

Saga Traffic

Step failure probability 12%

Spawn rate 1.0 / s

Live Metrics

In flight

Spawned

Completed

Compensated

Observed success

—

Predicted (1−p)^4

—

How it works

A saga replaces one giant cross-service database transaction (impossible once each microservice owns its own data store) with a chain of small local transactions T₁…Tₙ, one per service — here Order → Payment → Inventory → Shipping → Notify. Each Tᵢ commits on its own; there is no distributed lock spanning all five.

If a step fails, the saga cannot simply "roll back" a distributed commit — instead it runs compensating transactions in reverse order, each one semantically undoing the effect of its forward step (refund a payment, release reserved stock, cancel a shipment). This gives eventual consistency instead of atomicity.

P(all n downstream steps commit) = (1 − p)^n
n = 4 downstream legs here (Order→Payment→Inventory→Shipping→Notify)
Example: p = 0.12 → (0.88)^4 ≈ 0.60

Choreographed — each service reacts directly to the previous one's event; no central authority, shown as node-to-node lines on the chain.
Orchestrated — a central coordinator (the hub above the chain) explicitly calls each service; shown as hub-to-node spokes, and sagas detour through the hub on every leg.
Failure probability — chance any single downstream local transaction fails and triggers compensation.
Spawn rate — how many new saga instances enter the system per second.

The strip chart below the diagram tracks the rolling observed success rate against the theoretical prediction — drag the diagram to pan, scroll/pinch to zoom.

Real systems: order/payment/shipping pipelines at Uber, Amazon and most event-driven e-commerce backends use exactly this pattern to keep per-service databases independent while still reaching a consistent end state.

Forward (committing) Compensating (rollback) Node just committed

drag to pan · scroll to zoom