What Are Distributed Transactions and Why Are They Hard?

Why Distributed Transactions Are Hard: In a single database, transactions use local locks and a write-ahead log to guarantee atomicity. If the process crashes, recovery replays the log. But when a transaction spans multiple independent systems, there is no shared log or lock manager. Each participant can fail independently, and the network can partition between any two nodes. The fundamental problem: how do you ensure all participants commit or all abort when you cannot trust that messages will arrive or that nodes will stay alive? Two-Phase Commit (2PC): The Classic Solution Two-Phase Commit solves this by using a coordinator to orchestrate two rounds of communication. In the prepare phase, the coordinator asks each participant to vote on whether they can commit. Participants write their vote to stable storage (0.5 to 5 milliseconds on SSDs) and acquire all necessary locks. If all vote yes, the coordinator enters the commit phase and instructs everyone to finalize. Otherwise, it instructs an abort. This provides full ACID atomicity across distributed resources. The Blocking Problem: The major downside is that 2PC is a blocking protocol. If the coordinator crashes after participants have prepared but before issuing the commit decision, participants remain in an in-doubt state, holding locks and waiting for recovery. Latency depends on the slowest participant: single region commits typically take tens of milliseconds, but cross-region scenarios (50 to 150 milliseconds round-trip) push commit latency above 100 milliseconds. Google Spanner demonstrates 2PC at planetary scale by combining it with Paxos replicated participants and TrueTime for bounded clock uncertainty.