Distributed Transactions

You want to transfer $500 from your checking account to your savings account. On a single database, this is trivial, one transaction, two updates, ACID guarantees handle the rest. Either both updates happen, or neither does. Your money never disappears into the void.

Now imagine your checking account is on a database in Virginia and your savings account is on a database in Oregon. Same two updates, but across two independent database systems that know nothing about each other. How do you ensure atomicity, that both updates happen or neither does? If the Virginia update succeeds but the Oregon update fails, $500 vanishes from your checking account and never appears in savings. Congratulations, you've lost money.

This is the distributed transaction problem, and it has haunted database engineers since the 1970s. The fundamental challenge is that two independent systems can't atomically commit. System A commits its part and tells system B to commit, but the network fails before B receives the message. A has committed, B hasn't. The transaction is partially applied. Money is gone.

Every solution to this problem involves some form of coordination protocol, two-phase commit, three-phase commit, saga pattern, each with different trade-offs between safety, liveness, and performance. Understanding distributed transactions is understanding why microservices architecture is fundamentally harder than monolithic architecture, and why companies like Google spent a decade building Spanner.

A local transaction on a single database node relies on a simple mechanism: a transaction log (WAL). The database writes all changes to the log. If the transaction completes, it's committed. If the process crashes mid-transaction, the log is replayed on recovery, incomplete transactions are rolled back.

This doesn't work across nodes because there's no shared log. Each node has its own log, its own crash recovery, and its own idea of whether the transaction succeeded.

The core dilemma: To ensure atomicity across nodes, you need a coordinator that tells all nodes to commit simultaneously. But "simultaneously" doesn't exist in a distributed system, messages take time, arrive out of order, and sometimes don't arrive at all. The coordinator itself can fail. And during that failure window, participants are stuck, they've prepared to commit but haven't received the final "go" signal.

The approaches:

• Two-Phase Commit (2PC), the classic solution. Safe but blocking. One coordinator failure can freeze the entire transaction.
• Three-Phase Commit (3PC), adds a pre-commit phase to reduce blocking. Theoretically better, rarely used in practice.
• Saga Pattern, breaks the transaction into independent steps with compensating actions. No distributed locking, but weaker guarantees.
• Consensus-based (Raft/Paxos), used by Spanner, CockroachDB. Strong guarantees but high latency.