# Distributed transactions > A distributed transaction coordinates changes across multiple databases, shards, or services so participating writes commit or abort together. In system design interviews, the key decision is whether you need that atomic boundary or can use local transactions with explicit intermediate states and recovery. Source: https://sysround.com/concepts/distributed-transactions Updated: 2026-11-05 ## How distributed transactions works Start with the invariant and its storage boundary. If debiting account A and crediting account B happen in one database transaction, you may not need distributed coordination. If the accounts live on separate shards, keeping both changes atomic requires a transaction protocol supported by both shards. Two-phase commit (2PC) is a common atomic commit protocol. In the prepare phase, a coordinator asks each participant whether it can commit. Each participant durably records its prepared state and typically retains locks or other resources before voting yes. If every participant votes yes, the coordinator durably records a commit decision and tells participants to commit. Otherwise, it records an abort decision. Participants must recover and follow the recorded decision; a prepared participant cannot simply abort because a timeout expires. Failures make the protocol expensive. A participant that has voted yes may have to wait while the coordinator or decision record is unavailable. Replicating the coordinator's state improves resilience, but does not let the system safely complete every transaction through every network partition. Atomic commit is not the same as isolation. 2PC decides whether participating changes commit together; concurrency control determines which concurrent executions and reads are allowed. For a cross-shard transfer, specify both the all-or-nothing requirement and how concurrent withdrawals avoid overspending. When participants cannot join an atomic protocol, use a different model explicitly. A booking workflow might reserve a seat, authorize payment, and confirm the booking through local transactions coordinated by a saga. An outbox makes a local state change and its outgoing event atomic, but neither a saga nor an outbox creates one globally atomic transaction. ## Worked example: A $40 transfer across two account shards Account A has $100 on shard 1; account B has $20 on shard 2. A $40 transfer should leave balances of $60 and $60, with balanced ledger entries. Assume both shards support distributed transactions with serializable isolation. The coordinator asks both shards to prepare their balance and ledger changes. Once both vote yes, it durably records commit and sends the decision. If it crashes before notifying shard 2, shard 2 must recover the decision rather than independently abort. The client may receive a timeout even though the transfer committed. A unique transfer ID, enforced within the transaction, lets a retry return the existing result without moving another $40. ## Trade-offs - **Stronger atomicity, higher coordination cost.** Prepare and decision exchanges add network round trips and durable writes compared with a local transaction. - **Correctness can require waiting.** During failures, prepared participants may retain resources and block progress until they can recover the transaction decision. - **Long transactions amplify contention.** Holding locks across network calls can increase conflicts, tail latency, and the number of unrelated requests waiting. - **Participant support limits the boundary.** A database transaction generally cannot atomically include an external payment API, email delivery, or another system that does not support the protocol. - **Recovery becomes part of normal operations.** The system needs durable transaction records, retry-safe protocol messages, recovery procedures, and visibility into unresolved transactions. - **Sagas trade atomicity for workflow complexity.** Local commits avoid a single global atomic boundary but expose intermediate states and require compensations, reconciliation, and sometimes manual intervention. ## When to use it in a system design interview - A business invariant requires several writes across shards or databases to commit together, with no acceptable partially completed result. - Concurrent operations can violate a cross-partition constraint, and the database offers distributed transactions with suitable isolation. - An order or payment workflow spans independent systems, requiring an explicit choice between atomic commit and a recoverable saga. - The interviewer introduces a crash between two writes or an ambiguous timeout, forcing you to explain the transaction boundary and recovery behavior. ## How to bring it up in the interview - Name the invariant before naming a protocol: for example, every posted internal transfer must have balanced debit and credit entries. Then show whether the data can fit inside one local transaction. - Separate atomicity from isolation. Expect follow-up questions about concurrent withdrawals, write skew, stale reads, and whether the chosen isolation level actually preserves the invariant. - Walk through a crash after prepare and a crash after the commit decision. Explain where the decision is durable, who retries, and why a client timeout does not prove the transaction aborted. - For external services, explain what replaces atomicity: durable workflow state, stable idempotency keys, outcome lookup, compensating actions, and reconciliation. Expect questions about failed compensation and late payment success. - Defend the scope and cost. Keep atomic transactions short, avoid slow external calls inside them, and explain whether changing shard ownership or colocating related data can reduce coordination. ## Common mistakes - Calling a sequence of successful RPCs a transaction without explaining what happens when a later call fails. - Treating two-phase commit as a guarantee of serializable isolation or exactly-once external side effects. - Assuming a prepared participant can safely roll back on timeout, even though a commit decision may already exist. - Describing a saga compensation as a rollback that erases history; refunds and cancellations are new operations and can fail. - Reaching for distributed transactions before considering a single database transaction, data colocation, or a smaller consistency boundary. ## Interview questions where it comes up - [Design a wire transfer system](https://sysround.com/questions/design-wire-transfer-system): The central challenge is separating atomic internal ledger updates from uncertain transfers across an external bank boundary. - [Design a payment system](https://sysround.com/questions/design-payment-system): A good answer must define which ledger and balance updates commit together and how external payment outcomes are reconciled. - [Design a ticket booking system like Ticketmaster](https://sysround.com/questions/design-ticketmaster): Seat reservation and payment require an explicit consistency boundary and recovery when one succeeds without the other. - [Design a hotel booking system](https://sysround.com/questions/design-hotel-booking-system): Atomic multi-night inventory updates and payment-versus-expiration races require careful transaction scoping and failure handling. - [Design a food delivery app like DoorDash](https://sysround.com/questions/design-doordash): Coordinating payment, restaurant acceptance, and order state requires a recoverable cross-service workflow rather than an assumed global rollback. - [Design a stock trading app like Robinhood](https://sysround.com/questions/design-robinhood): Cash reservations and ledger updates need strong internal transaction boundaries while external execution outcomes remain independently uncertain. ## FAQ ### What is the difference between a local and a distributed transaction? A local transaction commits within one database transaction boundary. A distributed transaction coordinates multiple participants, such as database shards, so their writes share one commit-or-abort outcome. That coordination adds failure cases and communication overhead. ### What is the difference between two-phase commit and a saga? Two-phase commit coordinates one atomic outcome across participants that support the protocol. A saga commits individual steps separately and uses compensating actions when later steps fail. Sagas allow intermediate states and do not provide the isolation or all-or-nothing visibility of a single database transaction. ### How do microservices avoid distributed transactions? They often keep strict invariants inside one service's database and coordinate cross-service work through durable workflows. An outbox reliably publishes events from local commits, while idempotent consumers and sagas handle retries and partial progress. This changes the consistency contract rather than preserving global atomicity for free. ## Related concepts - [Two-phase commit](https://sysround.com/concepts/two-phase-commit) - [Saga pattern](https://sysround.com/concepts/saga-pattern) - [Transactional outbox pattern](https://sysround.com/concepts/outbox-pattern) - [Idempotency and idempotency keys](https://sysround.com/concepts/idempotency) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.