Two-Phase Commit (2PC)

The core guarantee of 2PC is atomicity across distributed nodes. It ensures that a transaction involving multiple participants is treated as an indivisible unit of work. The protocol's two-phase structure enforces that either:

• All participants commit the transaction, making its effects permanent.
• All participants abort the transaction, rolling back any tentative changes.

This prevents the system from entering an inconsistent state where some nodes have applied changes while others have not, which is critical for operations like distributed database updates or financial transfers across accounts on different servers.

2PC employs a central coordinator (or transaction manager) that directs the protocol. This creates a single point of failure and a potential performance bottleneck. The protocol is blocking because if the coordinator fails after sending prepare messages, participant nodes remain in an uncertain state, holding locks on resources until they receive a final decision. This can lead to:

• Resource deadlock, as participants cannot unilaterally decide to commit or abort.
• Reduced availability during coordinator downtime.

This characteristic is a primary motivation for the development of non-blocking protocols like Three-Phase Commit (3PC).

2PC is a synchronous protocol that requires all participating nodes to be available and responsive during the execution phases. The coordinator must wait for responses from every participant before proceeding to the next phase. This design makes it vulnerable to:

• Network partitions, which can stall the entire transaction.
• Slow nodes, as the protocol's latency is determined by the slowest respondent.

While robust within a stable, low-latency network, this synchronicity limits its suitability for highly dynamic or geographically dispersed systems where partial failures are common.

The protocol's operation is strictly divided into two sequential phases:

Phase 1: Prepare/Vote Phase

• The coordinator sends a prepare (or vote-request) message to all participants.
• Each participant performs local validation, writes transaction logs to stable storage, and then votes Yes (ready to commit) or No (must abort).
• A No vote or timeout immediately forces a global abort.

Phase 2: Commit/Abort Phase

• If all votes are Yes, the coordinator decides commit, logs this decision, and sends commit messages.
• Participants receive the commit order, make the transaction permanent, release locks, and send an ack.
• The coordinator completes the transaction after receiving all acknowledgments.

2PC is a classic example of prioritizing strong consistency (C) and partition tolerance (P) over availability (A) within the CAP theorem framework. During a network partition that isolates the coordinator or critical participants, the protocol will block or abort transactions to maintain consistency, sacrificing availability. This makes it ideal for systems where data integrity is paramount and operations can tolerate temporary unavailability, such as core banking systems or inventory management databases, but less suitable for highly available web services.

2PC is a fundamental building block for achieving atomic broadcast and State Machine Replication (SMR). In SMR, multiple replicas must apply the same sequence of commands in the same order to maintain identical states. 2PC can be used to coordinate the agreement on each command's entry into the replicated log. While higher-level consensus protocols like Raft or Paxos are often used for leader election and log replication, 2PC's transaction semantics are crucial for ensuring that multi-shard or multi-replica database updates are applied atomically across the replicated state machines.

A foundational family of protocols for achieving consensus in a network of unreliable processors. Unlike 2PC, which is a blocking protocol, Paxos is designed to be fault-tolerant and can make progress as long as a majority of participants are alive. It ensures that a single, agreed-upon value is chosen despite process failures. It is notoriously complex to implement correctly but forms the theoretical basis for many modern distributed systems.

• Key Use: Core consensus in systems like Google's Chubby lock service.
• Contrast with 2PC: Paxos solves consensus (agreeing on one value), while 2PC solves atomic commitment (all commit or all abort a transaction).

A consensus algorithm designed for understandability while providing the same fault tolerance as Paxos. It separates consensus into three sub-problems: leader election, log replication, and safety. A single elected leader manages the replication of a log to follower nodes. It is widely used in systems like etcd and Consul for managing replicated state machines.

• Key Use: Managing cluster membership and configuration state.
• Contrast with 2PC: Raft manages a replicated log for state machine replication, while 2PC coordinates a single transaction's outcome across heterogeneous resources.

A property of a distributed system that allows it to reach consensus and operate correctly even when some components fail arbitrarily (i.e., exhibit Byzantine or malicious behavior). Classical 2PC is non-Byzantine; it assumes participants fail by crashing but not by sending contradictory messages. BFT protocols, like Practical Byzantine Fault Tolerance (PBFT), are essential for trustless, adversarial environments such as some blockchain networks.

• Key Use: Securing blockchain networks and high-assurance military systems.
• Contrast with 2PC: 2PC cannot tolerate malicious coordinators or participants who lie.

A communication primitive that guarantees all correct processes in a system deliver the same set of messages in the same order. Solving Atomic Broadcast is equivalent to solving consensus. It is a core building block for State Machine Replication (SMR), where all replicas must process the same commands in the same order to maintain identical state.

• Key Use: Implementing replicated databases and ledger systems.
• Relationship to 2PC: While 2PC ensures atomicity of a single transaction's outcome, Atomic Broadcast ensures total order for a stream of messages, which can be used to coordinate multiple transactions.

An extension of 2PC designed to eliminate its blocking problem. It introduces an extra pre-commit phase between the vote and commit phases. This allows participants to know that everyone else voted to commit before moving to a point of no return. If the coordinator fails after the pre-commit phase, a new coordinator can safely commit the transaction without blocking indefinitely.

• Key Use: Distributed systems where coordinator failure is a critical risk.
• Trade-off: Reduces blocking at the cost of additional message rounds and complexity.

A failure management pattern for long-running transactions (LLTs) that achieves eventual consistency by breaking the transaction into a sequence of local, compensatable sub-transactions. Each sub-transaction has a corresponding compensating transaction (a rollback) that is executed if a later sub-transaction fails. This contrasts with 2PC's all-or-nothing atomicity and is better suited for microservices architectures.

• Key Use: Coordinating business processes across microservices (e.g., travel booking).
• Contrast with 2PC: Sagas provide eventual consistency and avoid long-lived locks, whereas 2PC provides strong atomicity but can block resources.