How many services participate in a typical transaction - 2, 5, 20?

10K transactions/sec aggregate. Median txn touches 3-5 services; tail touches 10+. 99% complete in <1s; long-tail (waiting for human / external API) can run for hours.

What's the latency budget for the end-to-end transaction - 100ms, 1s, 30s?

Orchestrated saga p99 < 500ms for a 5-step happy path. Compensation chain p99 < 2s. 2PC commit phase p99 < 50ms intra-DC.

gitGood.dev

Distributed Systems

Design Distributed Transactions (2PC, Saga, TCC)

Hard Premium

Two-phase commit, sagas (choreography vs orchestration), TCC, idempotency keys, and the compensation logic that turns multi-service writes into something a customer-support agent can untangle.

The problem

Design a transaction protocol that spans multiple independent services - payments, inventory, shipping, notifications - where each owns its own database and you cannot use a single ACID transaction across them. The end-state must be consistent: either every service commits its piece, or every service rolls back. Failures (network blips, service crashes, duplicate retries) must not leave the system half-committed.

This is the question that separates "I read the saga blog post" from "I have run this in production". Strong candidates explain why 2PC is rare in practice, walk through a concrete saga (orchestration vs choreography), justify their idempotency story, and own the failure modes - what happens when a compensating action itself fails.

Clarifying questions

Asking these before diving into a solution is the difference between a "hire" and a "no signal" rating. Pick the questions whose answers would change your design.

→How many services participate in a typical transaction - 2, 5, 20?
→Are the participating services all owned by us, or do some belong to third parties (Stripe, shipping carriers)?
→What's the latency budget for the end-to-end transaction - 100ms, 1s, 30s?
→Is partial visibility acceptable mid-transaction (e.g., order created but not yet paid), or must intermediate states be hidden?
→Throughput - hundreds, thousands, or tens of thousands of transactions/sec?
→Are compensations always possible, or are there irreversible steps (sending an SMS, charging a card)?
→Strong serializability across services required, or is read-your-writes within a service enough?
→What's the operator's escape hatch - a back-office tool to manually resolve stuck transactions?

Requirements

Functional requirements

·Begin a transaction spanning N services with a unique transaction ID
·Each step records its outcome (committed, failed, compensated) durably
·On any step failure, run the compensating action for every previously-committed step in reverse order
·Idempotent retries: a duplicate request for any step is a no-op, not a double-commit
·Visibility: observability of in-flight transactions, with operator tools for stuck ones
·Timeout policy: long-running transactions are detected and either compensated or escalated
·Audit log of every step transition for compliance and debugging

Non-functional requirements

Scale: 10K transactions/sec aggregate. Median txn touches 3-5 services; tail touches 10+. 99% complete in <1s; long-tail (waiting for human / external API) can run for hours.
Latency: Orchestrated saga p99 < 500ms for a 5-step happy path. Compensation chain p99 < 2s. 2PC commit phase p99 < 50ms intra-DC.
Availability: 99.9% for the coordinator. A coordinator outage stalls in-flight transactions but does not corrupt them - on recovery, the durable log resumes them.
Consistency: Eventual atomicity: every transaction reaches a terminal state (committed or fully compensated) within bounded time. No silent half-commits. Read isolation is per-service - cross-service consistency is best-effort during the saga window.

The full walkthrough covers

Architecture components

·Saga coordinator (orchestrator)
·Transaction log
·Participant service
·Idempotency store
·Event bus (for choreography)
·Compensation queue
·Stuck-transaction monitor
·Operator console
·Outbox publisher

Deep dives

2PC vs 3PC: why two-phase commit is rare in practice
Saga: choreography vs orchestration
Compensating actions: writing the undo and what 'undo' even means
TCC (Try-Confirm-Cancel): reservations as a 2PC alternative
Idempotency: keys, dedup tables, and the at-least-once contract
When to give up: choosing eventual consistency over distributed transactions

What's in the full walkthrough

Capacity estimation · architecture with all 9 components explained · 6 deep dives · trade-off analysis · 8 common follow-up questions

Subscribe to Continue

Get full access to gitGood.dev with a subscription.

Start Your 10-Day Trial

Try everything free for 10 days. Cancel anytime.

1,950+ practice questions
AI mock interviews (3/day)
Coding challenges with real execution
Verified skill badges
146 certification guides, 26 with practice exams

View Plans

10-day trial, then $5/mo - or $40/yr ($3.33/mo, save 33%). Cancel anytime.

Companies that test this topic

Senior Software Engineer

Practice in interview format

Reading is the floor. The interview signal is in walking through this live with someone probing follow-ups. Use the AI mock interview to practice talking through requirements, architecture, and trade-offs out loud.

Start an AI mock interview →