Two-Phase Commit (2PC)

2PC employs a single, central coordinator (or transaction manager) that drives the protocol. All participants (resource managers, e.g., databases) communicate solely with the coordinator. The coordinator's role is to:

• Initiate the transaction.
• Collect votes from all participants.
• Make the global commit/abort decision.
• Disseminate the final decision. This centralized design simplifies the decision logic but creates a single point of failure.

A critical flaw of 2PC is its blocking protocol. After a participant votes YES in the prepare phase, it enters a blocked or uncertain state. It must wait indefinitely for the coordinator's final decision (commit or abort). If the coordinator fails during this window, participants remain blocked, holding locks on resources, until the coordinator recovers. This can lead to system-wide hangs and reduced availability.

The core guarantee of 2PC is atomic commitment: either all participants commit their local transaction work, or all abort. This is achieved through the two-phase structure:

• Phase 1 (Prepare/Voting): Coordinator asks, "Can you commit?" Participants perform all checks, write log records, and lock resources. They reply YES (ready) or NO (abort).
• Phase 2 (Commit/Abort): If all votes are YES, coordinator sends COMMIT. If any vote is NO, coordinator sends ABORT. Participants act accordingly and acknowledge. No middle state where some commit and others abort is permitted.

2PC uses persistent logging at both coordinator and participants for crash recovery. Key logs include:

• Prepare Log Record: Written by participant before voting YES.
• Decision Log Record: Written by coordinator before sending commit/abort. On recovery, entities read their logs to resolve in-doubt transactions. However, recovery is complex. A participant recovering in the uncertain state must query other participants or the coordinator to discover the outcome—a process that can prolong blocking.

2PC is a synchronous and blocking protocol at every step. The coordinator must wait for responses from all participants in Phase 1 before proceeding to Phase 2. Similarly, it typically waits for acknowledgments in Phase 2. This synchronous waiting makes the protocol latency-sensitive; the entire transaction's latency is bounded by the slowest participant's response time. It is not suitable for geographically distributed systems with high network latency.

The canonical use case for 2PC is coordinating ACID transactions across multiple, heterogeneous database nodes or shards. A single logical transaction—like transferring funds between accounts stored on different database servers—requires all servers to agree on the commit. The coordinator (often the application or a transaction manager) uses 2PC to ensure atomicity, making the distributed system appear as a single, consistent database to the application. This is foundational for financial systems and inventory management where data integrity is non-negotiable.

In the Saga pattern for long-running business processes, 2PC is often unsuitable for the entire saga due to long-lived locks. However, it can be used to coordinate the commit phase of individual, short-lived local transactions within a saga step. For example, reserving inventory (Service A) and charging a credit card (Service B) must both succeed before proceeding. A 2PC protocol between these two services ensures the step is atomic before the saga moves to the next step, which will have its own compensating transaction if needed later.

Ensuring a message is published to multiple message brokers or topics atomically. Consider an event that must be sent to both an audit log queue and a workflow trigger queue. Using 2PC:

• Phase 1 (Prepare): The coordinator asks each queue broker if it can durably store the message.
• Phase 2 (Commit/Abort): If all brokers vote 'yes', the coordinator tells all to commit (store). If any vote 'no' (e.g., queue is full), the coordinator tells all to abort. This prevents a system where an audit event is logged but the workflow is never triggered, or vice-versa.

Orchestrating updates across several third-party SaaS APIs where a business operation requires all to succeed. Example: A user update must be propagated to a CRM (Salesforce), a marketing platform (HubSpot), and a billing system (Stripe). A 2PC coordinator can:

1. Call a 'prepare' endpoint on each service (if supported) to validate and stage the change.
2. If all stages succeed, call the 'commit' endpoint on each. This is challenging as many external APIs do not natively support a prepare phase, often requiring idempotent calls and compensating transactions (e.g., a rollback API call) for the abort case instead of a true 2PC.

In consensus algorithms like Raft or Paxos (which are used for different problems than 2PC), 2PC principles can be seen in how logs are replicated. Before a leader commits an entry to its own state machine, it must ensure the entry is replicated to a quorum of followers. This is analogous to a prepare phase. Once the quorum acknowledges, the leader commits (the second phase) and notifies followers to apply the entry. This ensures all replicas apply the same commands in the same order, maintaining strong consistency across the cluster.

XA is a specification for coordinating global transactions across multiple resource managers (e.g., databases, message queues) using a 2PC protocol. A transaction manager (like a Java EE server or a dedicated TM) acts as the coordinator. Resources that are 'XA-compliant' provide the necessary prepare, commit, and rollback interfaces. This is a standardized implementation of 2PC used in enterprise Java (JTA) and .NET ecosystems to manage transactions spanning different technologies. The trade-off is blocking and potential for heuristics (partial commits) during recovery.

A logically inverse operation designed to semantically undo the effects of a previously committed transaction. Unlike a simple database rollback, it is a new business operation that reverses the outcome. This is the core mechanism for rollback in the Saga pattern and is used when a system's state has been irreversibly communicated to external parties (e.g., an email was sent, a payment was processed).

• Example: If a 'Reserve Inventory' transaction commits, its compensating transaction is 'Release Inventory'.
• Critical Property: Compensating transactions must be idempotent to allow for safe retries.

A fault-tolerance technique where a system periodically saves a complete snapshot of its internal state (memory, variables, context) to persistent storage. This checkpoint serves as a known-good recovery point. In agentic systems, this allows for state reversion following a failure, rolling back the agent's internal logic and context to a point before the error occurred. It is the enabling mechanism for many rollback protocols.

• Granularity: Can be full (entire state) or incremental (only changes since last checkpoint).
• Challenge: Requires deterministic execution for replay to be consistent across replicas.

A fundamental class of algorithms that enable a group of distributed processes or agents to agree on a single value or state despite partial failures. Protocols like Raft and Paxos are used to reliably coordinate decisions—such as 'commit' or 'abort' in a distributed transaction or the validity of a shared checkpoint—across multiple replicas. 2PC is itself a simple consensus protocol for the specific decision of transaction commitment.

• Fault Models: Crash Fault Tolerance (CFT) handles nodes that stop; Byzantine Fault Tolerance (BFT) handles malicious/arbitrary behavior.
• Core Use: Maintaining a consistent, replicated log for state machine replication.

An operation that can be applied multiple times without changing the result beyond the initial application. This is a critical property for building resilient systems that use retries and rollbacks. If an agent's tool call or API execution is idempotent, it can be safely retried after a failure or network timeout without causing duplicate side effects (e.g., charging a customer twice).

• HTTP Example: PUT and DELETE methods are defined as idempotent; POST is not.
• Design Strategy: Use unique request IDs (idempotency keys) to allow servers to deduplicate repeated requests.