Distributed Transactions
Mechanisms that ensure a set of database operations spanning multiple independent nodes either all succeed (commit) or all fail (rollback) atomically, despite network partitions and node failures.
The CAP theorem (Brewer, 2000) states that a distributed system can guarantee only two of three: Consistency, Availability, Partition Tolerance. Since network partitions are inevitable in real systems, the practical choice is between CP (consistent but may be unavailable during partitions — preferred by financial databases) and AP (available but eventually consistent — preferred by large-scale web services).
graph LR
Center["Distributed Transactions"]:::main
Rel_decentralized_derivatives_pricing_models["decentralized-derivatives-pricing-models"]:::related -.-> Center
click Rel_decentralized_derivatives_pricing_models "/terms/decentralized-derivatives-pricing-models"
Rel_transaction_sharding["transaction-sharding"]:::related -.-> Center
click Rel_transaction_sharding "/terms/transaction-sharding"
Rel_decentralized_exchange_dex_order_book["decentralized-exchange-dex-order-book"]:::related -.-> Center
click Rel_decentralized_exchange_dex_order_book "/terms/decentralized-exchange-dex-order-book"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧠 Knowledge Check
🧒 Explain Like I'm 5
Imagine you're buying a concert ticket online. The website must do two things at exactly the same time: (1) take money from your bank, and (2) give you the ticket. If the bank's computer takes the money but the ticket computer crashes, you've paid but got nothing. A distributed [transaction](/en/terms/transaction) is the rule that says: 'BOTH must succeed, or BOTH must be completely reversed as if nothing happened.' It's an all-or-nothing deal across multiple computers.
🤓 Expert Deep Dive
Two-Phase Commit (2PC) — Blocking Failure Mode
In 2PC, the Coordinator sends PREPARE to all participants. Each participant flushes its intended changes to a write-ahead log (WAL) and responds YES/NO. If all say YES, the Coordinator sends COMMIT. The blocking hazard: if the Coordinator crashes after receiving all YES votes but before sending COMMIT, participants hold exclusive locks on their resources indefinitely. They cannot unilaterally abort (they already voted YES) and cannot commit (no coordinator instruction). Recovery requires the coordinator to restart and re-broadcast the decision.
Three-Phase Commit (3PC) — Non-Blocking but Partition-Unsafe
3PC adds a PRE-COMMIT phase: participants acknowledge they know all others are ready before committing. This allows participants to safely commit or abort without the coordinator if a timeout occurs — but only when the network is reliable. Under network partition, 3PC can result in split-brain decisions.
SAGA Pattern in Microservices
SAGAs replace distributed locking with eventual consistency. Each step T_i has a compensating transaction C_i. If T_3 fails, the orchestrator executes C_2, then C_1. SAGAs are choreography-based (events) or orchestration-based (a central saga orchestrator). The trade-off: SAGAs sacrifice Isolation (intermediate states are visible) for availability.
Blockchain: HTLCs and Atomic Swaps
Hash Time Lock Contracts (HTLCs) implement trustless cross-chain atomicity: Alice locks BTC with hash(secret); Bob locks ETH with the same hash. Alice reveals the secret to claim the ETH, simultaneously allowing Bob to use the secret to claim the BTC. If either party times out, funds are automatically returned.
❓ Frequently Asked Questions
What is the main problem with Two-Phase Commit (2PC)?
It is a blocking protocol. If the coordinator crashes after collecting all 'YES' votes but before sending the final COMMIT or ABORT decision, all participant nodes freeze, holding database locks indefinitely, until the coordinator recovers.
What is the SAGA pattern and why is it preferred in microservices?
A SAGA breaks a long transaction into smaller local transactions, each with a compensating transaction that undoes it. It avoids distributed locks, making services more available, but sacrifices strict isolation (intermediate states may be visible to other services).
How does a Hash Time Lock Contract (HTLC) enable trustless atomic swaps?
Both parties lock their assets using the same cryptographic secret hash. The first party reveals the secret to claim the other's asset, and this revelation automatically unlocks the secret for the second party to claim the first's asset. If either party doesn't act within the time limit, funds are refunded.