Distributed Transactions

Distributed transactions coordinate writes across multiple databases or services so they either all commit or all abort, maintaining data consistency. They introduce protocols like two-phase commit and saga patterns that trade off between consistency, availability, and complexity.

itDistributed systems, messaging, and integration

Don't Panic — Distributed Transactions

A distributed transaction is what happens when one business decision insists on visiting several independent systems and then expects them to behave like one database. This is a reasonable ambition. It is also where the network begins filing objections in triplicate.

The job is not to make every request arrive. The job is to preserve a business invariant when inventory, payment, and an order record do not share one local transaction. A crash between two successful actions leaves a partial story behind. Retrying without a stable identity can write the sequel twice.

The first useful distinction is between the business operation and the local transaction. A local transaction can make its own changes atomic. A coordinator, message flow, or recovery record must connect those local outcomes. The awkward surprise is that a timeout reports only that somebody stopped waiting. It does not announce whether the distant participant committed, aborted, or is now contemplating its paperwork.

Two-phase commit pursues one all-or-nothing outcome. Participants prepare durable state, then wait for a recorded decision to commit or abort. That protects atomicity, but prepared work can retain locks and wait when the decision is unavailable. It is a serious guarantee with a serious bill attached.

A saga chooses a different bargain. Each service commits its own step, and a later failure starts compensating transactions for earlier work. A refund, for example, is not an eraser for a charge; it is another durable business action. This is why compensation, retries, and progress tracking need design work rather than a hopeful catch block.

The transactional outbox handles a smaller but common nuisance: a database update that must cause a message. Store the business change and message intent in one local transaction, then let a relay publish later. Delivery can repeat, so consumers still need idempotency.

Read the intro for the full map of 2PC, XA, sagas, and outboxes. Use the slides when comparing failure paths, the cheatsheet when reviewing a design, and the practice reference when turning an invariant into a recovery ledger. The quiz is there to ensure that timeouts have not quietly become verdicts.

Don't Panic — Distributed Transactions

Relevant careers