All experiments
EXPERIMENT 02 / Distributed transactions

Saga.

A business transaction, several local commits. Plan what happens when a step fails.

HOW TO READ THIS

Change one thing at a time.
The interesting part is usually why it moved.

Interactive experiment STEP 00
Switching approach resets the experiment

A checkout is only as complete as its last local transaction.

Saga: Naive workflowOrder to Inventory, reserve. Inventory to Payment, authorize. Start an order, reserve stock, then try authorizing payment.reserveauthorizeSERVICEOrderreadyDATABASEInventoryNo reservationEXTERNALPaymentReady
serviceOrderready→ Inventory · reserve
databaseInventoryNo reservation→ Payment · authorize
externalPaymentReadyReceives work
Baseline systemSynchronous requestDeterministic · step by step
Stock reserved0
Orders complete0
Compensations0
Workflowready
Observation

Start an order, reserve stock, then try authorizing payment.

This example assumes stock release succeeds. Real compensation must be durable, idempotent and recoverable too.

THE PROBLEM

An order crosses independently owned stores. Payment can fail after stock has already been reserved.

This lab uses an orchestrated checkout with compensable reservations. Local commits are visible before the whole workflow finishes.

EVERY DECISION HAS A COST

What this buys, and what it charges you for.

Context, not a scorecard
Without the patternWith the patternILLUSTRATIVE / 0–100
ResilienceHigher is preferable
47+

An explicit compensation path releases this failed order’s reservation.

CouplingLower is preferable
31+

Stores remain independent, but participants still share workflow contracts.

ConsistencyHigher is preferable
43+

Local transactions commit separately. Other operations can observe intermediate states.

Operational complexityLower is preferable
52+

Operators need correlation, resumable workflows and tools for failed compensation.

Illustrative scores for this scenario, on a 0–100 scale. They express a direction of change, not a benchmark. Your constraints can change the result. Select a quality to explore the reasoning.

+ What improves

  • Coordinate a workflow across independent stores.
  • Make business recovery explicit.

± What gets harder

  • Compensation is a new business action, not an ACID rollback.
  • Intermediate states are visible; isolation needs separate design.
  • A saga gives up the I in ACID. Other operations can read partial results, so anomalies have to be handled with deliberate countermeasures rather than assumed away.
GO A LAYER DEEPER

Where the edges are.

A pattern is only useful once you know where it stops working. These are the boundaries worth knowing before you commit to it.

When it earns its place
  • A long-running workflow spans stores and accepts temporary inconsistency.
When to leave it out
  • A single database transaction fits, or partial effects are unacceptable.
New ways to fail
  • Compensation can fail and require intervention.
  • Duplicate delivery can repeat a charge without idempotency.
Operating the pattern
  • Persist workflow state; monitor stuck steps and failed compensation.
The people behind the system
  • Teams must own recovery contracts as carefully as success contracts.
Other directions to consider
  • A local ACID transaction
  • Reservation and confirmation
  • Two-phase commit where supported