Distributed transactions

Overview

A distributed transaction updates data in multiple databases or services atomically: all changes commit or none do. The classic protocol is two-phase commit (2PC): a coordinator asks all participants to prepare (lock and promise to commit), and if all vote yes, tells them to commit. 2PC is correct but blocking: if the coordinator fails after prepare, participants hold locks until it recovers.

In microservices, 2PC is usually avoided in favor of sagas (a sequence of local transactions with compensating actions), the transactional outbox pattern (publish events reliably with the local transaction), and idempotent consumers. Distributed SQL databases (Spanner, CockroachDB) implement distributed transactions internally with consensus to avoid 2PC's blocking problem.

When to use it

• Operations spanning multiple databases or services.
• Choosing between 2PC, sagas, and outbox patterns.
• Keeping a database write and an event publish consistent.
• Interview questions about order, payment, and inventory flows.

Where it shows up in interviews

Where it is used in real software

Key terms

Two-phase commit

Prepare phase, then commit or abort phase, driven by a coordinator.

Saga

Local transactions with compensating actions on failure.

Transactional outbox

Store events in the same DB transaction and publish them asynchronously.

Compensation

An action that semantically undoes a previous step (refund).

In-doubt transaction

A participant that prepared but does not know the outcome.

How it works, step by step

1. 1
   Coordinator sends PREPARE

   Participants lock resources and write a prepare record.

2. 2
   Participants vote

   YES (can commit) or NO.

3. 3
   Coordinator decides

   All YES: commit; any NO or timeout: abort. Decision is logged durably.

4. 4
   Coordinator sends the decision

   Participants commit or roll back and release locks.

5. 5
   Recovery

   In-doubt participants ask the coordinator for the outcome after failures.

2PC vs saga vs outbox

Choosing a cross-service consistency pattern

Microservices usually combine sagas for business flows with the outbox pattern for each local step.

Implementation

1// Write business data and the event atomically in one local transaction2export async function placeOrder(order: NewOrder) {3  await db.transaction(async (tx) => {4    const { id } = await tx.one("INSERT INTO orders (user_id, total_cents, status) VALUES ($1, $2, 'pending') RETURNING id",5      [order.userId, order.totalCents]);6    await tx.none("INSERT INTO outbox (aggregate_id, type, payload) VALUES ($1, 'OrderPlaced', $2)",7      [id, JSON.stringify({ orderId: id, ...order })]);8  });9}10 11// Relay (or Debezium CDC) publishes outbox rows to Kafka, then marks them sent12export async function relayOutbox() {13  const rows = await db.any("SELECT * FROM outbox WHERE sent_at IS NULL ORDER BY id LIMIT 100 FOR UPDATE SKIP LOCKED");14  for (const row of rows) {15    await kafka.send({ topic: "orders", messages: [{ key: row.aggregate_id, value: row.payload, headers: { eventId: String(row.id) } }] });16    await db.none("UPDATE outbox SET sent_at = now() WHERE id = $1", [row.id]);17  }18}

Complexity and performance

Trade-offs

Variants and related techniques

Common mistakes

• Dual writes: update the DB then publish to Kafka separately.

  Fix: One can fail; use the outbox pattern or CDC.

• Using 2PC across microservices owned by different teams.

  Fix: Tight coupling and blocking; prefer sagas.

• Compensations that are not idempotent.

  Fix: Compensations are retried too; make them idempotent.

Interview questions

Practice problems