Two-Phase Commit (2PC)

2PC's core function is to provide atomicity for distributed transactions. This means the entire transaction across all participating nodes is treated as a single, indivisible unit of work. The protocol guarantees that either:

• All nodes commit their changes permanently.
• All nodes abort and roll back to the previous state.

This prevents the system from entering an inconsistent 'half-committed' state, which is critical for financial systems or any operation requiring strict data integrity.

The protocol relies on a central Transaction Coordinator (TC). This node does not hold data but manages the protocol's two phases:

1. Phase 1 - Voting: The coordinator asks all participant nodes (cohorts) if they are prepared to commit. Each node performs its local work, writes all changes to a durable log, and votes YES (if ready) or NO (if unable).
2. Phase 2 - Decision: Based on unanimous YES votes, the coordinator sends a GLOBAL-COMMIT command. If any vote is NO, it sends GLOBAL-ABORT. Participants then enact the decision and acknowledge.

This design centralizes control logic but makes the coordinator a single point of failure.

A major drawback of 2PC is its blocking nature. After voting YES in Phase 1, a participant enters a prepared state and is blocked, holding resources (like locks) until it receives the coordinator's final decision.

If the coordinator fails after cohorts vote YES but before sending the decision, cohorts are blocked indefinitely. They cannot unilaterally decide to commit or abort without risking inconsistency. Systems implement timeout mechanisms to detect coordinator failure, but resolving a blocked transaction requires complex recovery protocols and can lead to reduced availability.

In multi-agent systems, 2PC can coordinate state changes across agents that manage different pieces of a shared memory or knowledge graph. For example, when an agentic workflow requires updating multiple, independent vector databases or CRDT states as a single logical operation, 2PC ensures all updates are applied atomically.

However, its synchronous and blocking nature is often at odds with the asynchronous, fault-tolerant design goals of modern agent systems, leading to the use of alternative patterns like Saga or eventual consistency models for long-running transactions.

It's crucial to distinguish 2PC from consensus protocols like Paxos or Raft:

• 2PC (Atomic Commitment): Assumes all nodes are working correctly during execution. Its goal is to get unanimous agreement on the outcome of a pre-determined transaction. It is not designed to tolerate Byzantine faults.
• Paxos/Raft (State Machine Replication): These protocols are used to agree on a sequence of commands (a log) across replicas, even in the face of node failures. They elect a leader and replicate logs to achieve strong consistency.

2PC is often used on top of a replicated log system; Raft can be used to replicate the coordinator's decision log to make it fault-tolerant.

For correctness after failures, both the coordinator and participants must write persistent log records at critical points:

• Coordinator Logs: prepare sent, global-commit or global-abort decision.
• Participant Logs: prepare received, vote (yes/no), final decision received.

On recovery after a crash, a node reads its log to determine its pre-crash state. A participant that logged yes but no final decision must query the coordinator or other participants to discover the outcome. This write-ahead logging is essential but contributes to the protocol's latency.

A foundational family of consensus protocols that enables a collection of distributed nodes to agree on a single value despite failures. Unlike 2PC, which coordinates a transaction's outcome, Paxos solves the broader problem of state machine replication and log consensus. It is more fault-tolerant than 2PC, as it can handle node failures during the voting process itself. Key components include proposers, acceptors, and learners.

• Core Use: Agreeing on the sequence of commands in a replicated log.
• Fault Tolerance: Survives failures of f nodes in a system of 2f + 1 nodes.
• Relation to 2PC: Often used as a more robust underlying layer to implement transaction coordinators.

A consensus algorithm designed for understandability, which manages a replicated log. It elects a single leader responsible for accepting client commands, replicating them to follower nodes, and managing commit safety. Raft provides strong consistency and is often used to build highly available, coordinated storage systems that underpin distributed transactions.

• Leader-Based: Simplifies logic compared to Paxos's multi-proposer model.
• Log Replication: The core mechanism for ensuring all nodes have the same command sequence.
• System Context: Can be the substrate upon which a 2PC coordinator is implemented to ensure its own state is fault-tolerant.

An extension of 2PC designed to reduce blocking in the face of coordinator failure. It introduces an additional pre-commit phase between the vote and the final commit/abort. This phase ensures that all participants know others are ready to commit before the point of no return. If the coordinator fails after pre-commit, participants can safely commit independently, avoiding the indefinite blocking possible in 2PC.

• Key Improvement: Non-blocking under certain failure scenarios.
• Trade-off: Increased message complexity and latency due to the extra round of communication.
• Use Case: Systems where coordinator availability is a critical concern.

A failure management pattern for long-running transactions that breaks a business process into a sequence of local transactions. Each local transaction updates the database and publishes an event or message to trigger the next step. If a step fails, compensating transactions are executed to undo the effects of the preceding steps. This contrasts with 2PC's all-or-nothing atomicity, favoring eventual consistency and better scalability.

• Architecture Style: Choreography (events) or Orchestration (central coordinator).
• Advantage over 2PC: Avoids long-lived locks on resources, improving scalability.
• Disadvantage: Application logic must define and implement rollback compensations.

A data structure designed for coordination-free concurrent updates in distributed systems. CRDTs are mathematically guaranteed to converge to the same state across all replicas, regardless of the order of operations, as long as all updates are eventually delivered. This provides a strong alternative to 2PC for data where immediate strong consistency can be relaxed in favor of availability and partition tolerance.

• Core Property: Commutative, associative, and idempotent operations.
• Consistency Model: Provides Strong Eventual Consistency.
• Contrast with 2PC: Eliminates the need for a prepare/commit protocol, enabling always-writable replicas.

A service that provides mutually exclusive access to resources (e.g., a memory segment, a file, a data record) across nodes in a distributed system. DLMs are often a lower-level primitive used to implement isolation guarantees for transactions coordinated by protocols like 2PC. They manage lock acquisition, renewal, and release, often using leases to prevent deadlock from failed nodes.

• Primary Function: Serialize access to shared resources.
• Implementation: Can use consensus protocols (like Raft) for fault tolerance.
• Relation to 2PC: A 2PC participant may acquire a DLM lock on a resource during the transaction's execution phase.