The Coordinator

Model Answer

In 2PC, a coordinator sends PREPARE to all participants; each votes YES (durably logs the tentative commit) or NO. If all vote YES, coordinator sends COMMIT; otherwise ABORT. Blocking problem: if the coordinator crashes after collecting YES votes but before sending COMMIT, participants are stuck holding locks indefinitely — they cannot unilaterally abort (might conflict with a commit the coordinator decided). Production solutions: (1) Replicate the coordinator using Raft so another node takes over, (2) Store coordinator decisions in a shared store participants can read (Percolator/Spanner approach), (3) Use timeouts with careful retry logic and human intervention for stuck transactions.

Model Answer

A distributed transaction (2PC-based) provides atomicity: all participants commit or none do. Intermediate states are not visible. Requires coordination and can block on failures. A saga is a sequence of local transactions, each with a compensating transaction. If step k fails, compensating transactions for steps 1..k-1 are executed. Intermediate states are visible. No coordinator blocking — each step acknowledges independently. Sagas are preferred in microservices architectures because they avoid distributed locking and work across services with different storage systems. Tradeoff: sagas do not provide isolation — concurrent sagas can interfere with each other.

Model Answer

Options by consistency requirement: (1) 2PC with a coordinator (strong atomicity, blocking on coordinator failure), (2) Saga: debit A, then credit B; if credit fails, execute compensating transaction to re-credit A (eventual consistency, intermediate state visible), (3) Outbox pattern: write debit and a "pending credit" event to the same DB transaction on A's side; a separate process reads the outbox and applies the credit to B, retrying until success (at-least-once delivery). For financial systems, option 3 with idempotency keys is common because it avoids distributed coordination while ensuring eventual consistency.

Model Answer

XA is a standard interface for distributed transactions, supported by most relational databases (Postgres, MySQL, Oracle) and message brokers. An XA transaction coordinator manages 2PC across multiple XA-capable resources. It is still used in enterprise Java applications (JTA/JTS) and mainframe-style architectures. It is generally avoided in modern distributed systems because: high latency (multiple round-trips per transaction), coordinator as SPOF, poor performance at scale. Cloud-native systems prefer sagas or application-level 2PC over a Raft-replicated coordinator.

Model Answer

Spanner uses 2PC where each shard is a Paxos group (not a single node). The 2PC coordinator is a Paxos leader (highly available, no single point of failure for blocking). TrueTime provides bounded clock uncertainty — Spanner assigns commit timestamps that are guaranteed to be after all prior transactions by waiting out the TrueTime uncertainty interval (commit wait). This ensures any transaction that starts after commit T will see the committed write, providing external consistency without a global sequencer. CockroachDB replicates this using Raft per range and Hybrid Logical Clocks instead of TrueTime.