Three-Phase Commit Protocol: Building Reliable Distributed Systems

Introduction and Core Concepts

The three-phase commit protocol (3PC) is a distributed consensus algorithm designed to ensure atomic commitment across multiple nodes in a distributed system. It extends the classic two-phase commit protocol (2PC) to eliminate the blocking problem that can leave participants in an uncertain state indefinitely when the coordinator fails. In any distributed transaction, all participants must unanimously agree to either commit or abort; 3PC provides a non-blocking guarantee under certain failure assumptions, making it a foundational concept for building reliable distributed systems.

At its core, the three-phase commit protocol addresses the atomic commitment problem. Imagine a banking system where money is transferred between accounts hosted on different database shards, or an e-commerce platform where inventory, payment, and shipping services must all succeed or all fail together. Without an atomic commit protocol, a partial failure could lead to money being deducted without being credited, or an order being charged without inventory being reserved. The three-phase commit protocol ensures that even in the presence of node crashes and network delays, the system reaches a consistent decision.

The protocol operates under the assumption of a fail-stop model with bounded network delays and uses timeouts to make progress. It introduces an additional intermediate phase between the voting and commit phases of 2PC, which allows participants to make a deterministic decision even if the coordinator disappears. While this adds latency and message overhead, it provides a crucial liveness property: no participant remains blocked forever waiting for a coordinator to recover. Understanding 3PC is essential for distributed systems engineers because it illustrates the fundamental trade-offs between consistency, availability, and performance, and directly informs modern consensus protocols.

Why Two-Phase Commit Is Not Enough

Two-phase commit is simple and widely used, but it has a critical weakness: it is a blocking protocol. If the coordinator crashes after participants have voted YES and entered the prepared state, those participants cannot unilaterally decide to commit or abort. They must wait until the coordinator recovers and informs them of the final decision, holding locks and resources the entire time. In a large-scale system, this blocking can cascade into severe availability problems.

The three-phase commit protocol was introduced by Dale Skeen and Michael Stonebraker in 1983 to solve this exact problem. By adding a pre-commit phase, 3PC ensures that if any participant is uncertain, it can safely abort, and if any participant has received a pre-commit, the group can safely commit without the coordinator. This transforms a blocking protocol into a non-blocking one, provided the network does not partition.

Core Assumptions and Guarantees

3PC provides strong guarantees under specific assumptions. It assumes fail-stop failures where crashed nodes stop executing and can be detected via timeouts, and it assumes no network partitions occur — messages are eventually delivered within a known bounded delay. Under these conditions, 3PC guarantees atomicity (all commit or all abort), consistency, and non-blocking termination. However, it is important to note that 3PC is not partition-tolerant; in the presence of a network partition, it can violate safety. This limitation is why modern systems often prefer Paxos or Raft for partition-tolerant consensus.

How It Works

The three-phase commit protocol divides the atomic commitment process into three distinct phases: CanCommit, PreCommit, and DoCommit. Each phase involves a round of messages between a single coordinator and multiple participants (also called cohorts). The coordinator drives the protocol, while participants respond to requests and maintain durable state transitions to survive crashes.

The key innovation is the second phase, PreCommit. This phase acts as a buffer state. A participant only enters the PreCommit state after all participants have agreed to commit. This creates a crucial invariant: if any participant is in the PreCommit state, then all participants have voted YES. Therefore, if a participant times out waiting for the coordinator and finds that at least one other participant is in PreCommit, it knows it is safe to commit. If no participant is in PreCommit, it is safe to abort.

State transitions are carefully designed to be recoverable. Both coordinator and participants log their state to stable storage before sending messages, enabling correct recovery after a crash. The protocol relies heavily on timeouts for failure detection, which is why bounded network delay is a prerequisite.

Phase 1: CanCommit (Voting Phase)

The coordinator initiates the transaction by sending a CanCommit? message to all participants. This is essentially asking, "Are you prepared to commit this transaction?" Each participant checks its local conditions — whether it can acquire necessary locks, validate constraints, and durably prepare the transaction — and replies with YES or NO. A YES vote means the participant promises to be able to commit if asked, while a NO vote is a veto that forces the entire transaction to abort. Participants also start a timer at this point.

Phase 2: PreCommit (Preparation to Commit)

If the coordinator receives YES from all participants, it moves to the PreCommit phase and broadcasts a PreCommit message. Upon receiving PreCommit, each participant acknowledges with an ACK and transitions to the prepared-to-commit state. This ACK is critical; the coordinator will only proceed to the final phase after receiving ACKs from all participants. If any participant voted NO or fails to respond within the timeout, the coordinator broadcasts an Abort message instead, and the protocol terminates.

Phase 3: DoCommit (Commit Phase)

Once the coordinator has collected all ACKs from the PreCommit phase, it sends a DoCommit message. Participants receiving DoCommit commit the transaction, release locks, and send a final ACK. If a participant times out waiting for DoCommit after having entered PreCommit, it can independently decide to commit after consulting other participants. This is the non-blocking property in action. The termination protocol, executed when timeouts occur, allows survivors to elect a new coordinator and reach consensus based on their collective states.

Implementation

Implementing the three-phase commit protocol correctly requires careful state management, persistent logging, and timeout handling. The following Python examples illustrate the core logic for both coordinator and participant roles. Note that production implementations would require durable write-ahead logging, RPC frameworks, and robust failure detectors.

The coordinator maintains a state machine with states: INIT, WAIT_FOR_VOTES, WAIT_FOR_PRECOMMIT_ACKS, and COMMITTED/ABORTED. The participant maintains states: INIT, PREPARED, PRECOMMITTED, and COMMITTED/ABORTED. Both must log state transitions before sending messages to ensure crash recovery is safe.

# Coordinator implementation for Three-Phase Commit Protocol
import time
import logging
from enum import Enum

class CoordinatorState(Enum):
    INIT = "INIT"
    WAIT_VOTES = "WAIT_VOTES"
    WAIT_ACKS = "WAIT_ACKS"
    COMMITTED = "COMMITTED"
    ABORTED = "ABORTED"

class Coordinator:
    def __init__(self, participants, timeout=5):
        self.participants = participants  # list of participant stubs
        self.state = CoordinatorState.INIT
        self.timeout = timeout
        self.log = []  # in production, use write-ahead log on disk

    def log_state(self, state, msg=""):
        # MUST log before sending messages for recovery safety
        entry = f"{state.value}: {msg}"
        self.log.append(entry)
        logging.info(entry)

    def execute_transaction(self, transaction):
        # Phase 1: CanCommit
        self.log_state(CoordinatorState.WAIT_VOTES, "Sending CanCommit")
        votes = []
        for p in self.participants:
            try:
                vote = p.can_commit(transaction, timeout=self.timeout)
                votes.append(vote)
            except TimeoutError:
                votes.append("NO")  # timeout treated as NO vote

        # If any NO, abort
        if any(v == "NO" for v in votes):
            self.log_state(CoordinatorState.ABORTED, "Aborting - vote failed")
            for p in self.participants:
                p.abort(transaction)
            return False

        # Phase 2: PreCommit
        self.log_state(CoordinatorState.WAIT_ACKS, "Sending PreCommit")
        acks = []
        for p in self.participants:
            try:
                ack = p.pre_commit(transaction, timeout=self.timeout)
                acks.append(ack == "ACK")
            except TimeoutError:
                acks.append(False)

        if not all(acks):
            self.log_state(CoordinatorState.ABORTED, "Aborting - PreCommit ACK failed")
            for p in self.participants:
                p.abort(transaction)
            return False

        # Phase 3: DoCommit
        self.log_state(CoordinatorState.COMMITTED, "Sending DoCommit")
        for p in self.participants:
            try:
                p.do_commit(transaction)
            except TimeoutError:
                # participant will recover via termination protocol
                logging.warning(f"DoCommit timeout for {p.id}")
        return True

# Participant implementation for Three-Phase Commit Protocol
from enum import Enum
import time

class ParticipantState(Enum):
    INIT = "INIT"
    PREPARED = "PREPARED"          # voted YES, waiting for PreCommit/Abort
    PRECOMMITTED = "PRECOMMITTED"  # received PreCommit, ready to commit
    COMMITTED = "COMMITTED"
    ABORTED = "ABORTED"

class Participant:
    def __init__(self, pid, can_commit_fn):
        self.id = pid
        self.state = ParticipantState.INIT
        self.can_commit_fn = can_commit_fn  # application-specific validation
        self.log = []
        self.data_store = {}

    def log_state(self, state):
        self.log.append(state)
        # In production: fsync to stable storage before replying
        self.state = state

    def can_commit(self, tx, timeout=5):
        # Phase 1 handler: check if we can commit
        if self.can_commit_fn(tx):
            self.log_state(ParticipantState.PREPARED)
            # Acquire locks, write undo/redo log
            return "YES"
        else:
            self.log_state(ParticipantState.ABORTED)
            return "NO"

    def pre_commit(self, tx, timeout=5):
        # Phase 2 handler: move to precommitted
        if self.state == ParticipantState.PREPARED:
            self.log_state(ParticipantState.PRECOMMITTED)
            return "ACK"
        return "ABORTED"

    def do_commit(self, tx):
        # Phase 3 handler: finalize commit
        if self.state == ParticipantState.PRECOMMITTED:
            self.log_state(ParticipantState.COMMITTED)
            # Apply writes, release locks
            self.data_store[tx.id] = tx.data
            return "ACK"
        elif self.state == ParticipantState.PREPARED:
            # Should not happen in normal execution; timeout case
            # Termination protocol will decide
            return "ABORTED"

    def abort(self, tx):
        self.log_state(ParticipantState.ABORTED)
        # Release locks, discard tentative writes
        return "ACK"

    def handle_timeout(self, peers):
        # Termination protocol invoked on coordinator timeout
        # Consult peer states to decide commit/abort
        peer_states = [p.state for p in peers if p.state != ParticipantState.INIT]
        if any(s == ParticipantState.COMMITTED for s in peer_states):
            self.log_state(ParticipantState.COMMITTED)
            return "COMMIT"
        if any(s == ParticipantState.PRECOMMITTED for s in peer_states):
            # Someone precommitted -> all voted YES, safe to commit
            self.log_state(ParticipantState.COMMITTED)
            return "COMMIT"
        if any(s == ParticipantState.PREPARED for s in peer_states):
            # No one precommitted, but someone prepared -> safe to abort
            self.log_state(ParticipantState.ABORTED)
            return "ABORT"
        # All init/aborted -> abort
        self.log_state(ParticipantState.ABORTED)
        return "ABORT"

# Simulation of timeout and coordinator failure handling
import random
import threading

class NetworkSimulator:
    def __init__(self, loss_rate=0.1, delay_range=(0.01, 0.2)):
        self.loss_rate = loss_rate
        self.delay_range = delay_range

    def send(self, sender, receiver, message):
        # Simulate network delay and possible loss
        delay = random.uniform(self.delay_range[0], self.delay_range[1])
        time.sleep(delay)
        if random.random() < self.loss_rate:
            raise TimeoutError(f"Message lost: {message} from {sender} to {receiver}")
        return receiver.receive(message)

class FailureDetector:
    def __init__(self, timeout=2.0):
        self.timeout = timeout

    def wait_with_timeout(self, func, *args, **kwargs):
        result = [None]
        exception = [None]
        def target():
            try:
                result[0] = func(*args, **kwargs)
            except Exception as e:
                exception[0] = e
        thread = threading.Thread(target=target)
        thread.start()
        thread.join(timeout=self.timeout)
        if thread.is_alive():
            raise TimeoutError("Operation timed out - coordinator suspected failed")
        if exception[0] is not None:
            raise exception[0]
        return result[0]

# Example usage of failure detection in participant
def participant_termination_example():
    detector = FailureDetector(timeout=1.5)
    participants = [Participant(f"P{i}", lambda tx: True) for i in range(3)]
    # Simulate coordinator crash after PreCommit
    # Participants run termination protocol among themselves
    for p in participants:
        try:
            detector.wait_with_timeout(p.pre_commit, "tx1")
        except TimeoutError:
            # Coordinator failed, run termination protocol
            decision = p.handle_timeout([q for q in participants if q != p])
            print(f"Participant {p.id} decided: {decision} after timeout")
            # If decision is COMMIT and state is PRECOMMITTED, commit
            if decision == "COMMIT" and p.state == ParticipantState.PRECOMMITTED:
                p.do_commit("tx1")

# Persistent logging and recovery for crash-restart
import json
import os

class PersistentLog:
    def __init__(self, log_file):
        self.log_file = log_file
        # Ensure log file exists
        if not os.path.exists(log_file):
            open(log_file, 'w').close()

    def append(self, record):
        # Write-ahead logging: fsync before returning
        with open(self.log_file, 'a') as f:
            f.write(json.dumps(record) + "\n")
            f.flush()
            os.fsync(f.fileno())

    def read_all(self):
        records = []
        with open(self.log_file, 'r') as f:
            for line in f:
                if line.strip():
                    records.append(json.loads(line))
        return records

class RecoverableParticipant(Participant):
    def __init__(self, pid, can_commit_fn, log_file):
        super().__init__(pid, can_commit_fn)
        self.persistent_log = PersistentLog(log_file)
        self.recover()

    def log_state(self, state):
        # Override to make durable
        self.persistent_log.append({"state": state.value, "id": self.id})
        self.state = state

    def recover(self):
        # Called on restart after crash
        records = self.persistent_log.read_all()
        if not records:
            self.state = ParticipantState.INIT
            return
        last_state = records[-1]["state"]
        self.state = ParticipantState(last_state)
        print(f"Participant {self.id} recovered to state {self.state}")
        # Recovery rules:
        # If PREPARED: contact peers/coordinator to learn outcome
        # If PRECOMMITTED: can commit after termination protocol
        # If COMMITTED/ABORTED: no action needed, already decided
        if self.state == ParticipantState.PREPARED:
            print("  -> Need to run termination protocol (was PREPARED)")
        elif self.state == ParticipantState.PRECOMMITTED:
            print("  -> Can commit via termination protocol (was PRECOMMITTED)")

# Example: crash and recovery
# p = RecoverableParticipant("P1", lambda tx: True, "/tmp/p1.log")
# p.can_commit(tx)  # logs PREPARED durably
# # ... crash happens here ...
# p2 = RecoverableParticipant("P1", lambda tx: True, "/tmp/p1.log")  # recovers

These implementations highlight three critical engineering requirements: all state transitions must be logged to stable storage before acknowledgments are sent, timeouts must be carefully tuned to avoid false failure suspicions, and the termination protocol must be available to all participants to guarantee non-blocking progress.

Step-by-Step Example

Consider a distributed e-commerce transaction involving three participants: an Inventory Service (P1), a Payment Service (P2), and a Shipping Service (P3), coordinated by an Order Coordinator (C). The transaction T1 represents a customer order that must atomically reserve inventory, charge payment, and schedule shipping.

We will walk through both a successful commit and a failure scenario to illustrate how the three-phase commit protocol handles each case.

Scenario A: Successful Commit (No Failures)

Step 1 - CanCommit Phase: Coordinator C sends CanCommit(T1) to P1, P2, and P3. P1 checks inventory and finds the item in stock, replies YES and enters PREPARED. P2 validates the credit card and replies YES, entering PREPARED. P3 confirms shipping capacity and replies YES, entering PREPARED. All votes are YES.

Step 2 - PreCommit Phase: Since all votes were YES, C logs its intent to pre-commit and broadcasts PreCommit(T1) to all participants. Each participant receives PreCommit, transitions from PREPARED to PRECOMMITTED, logs this state durably, and replies ACK. C waits until it has received ACKs from all three participants.

Step 3 - DoCommit Phase: After collecting all three ACKs, C broadcasts DoCommit(T1). Each participant receives DoCommit, transitions to COMMITTED, applies its local changes (P1 decrements inventory, P2 captures payment, P3 creates shipping label), and replies ACK. The transaction is now globally committed.

At this point, even if C crashes immediately after sending DoCommit to only one participant, the remaining participants can recover correctly. Any participant in PRECOMMITTED that times out can query peers; since at least one peer is PRECOMMITTED or COMMITTED, they will all decide to commit.

Scenario B: Coordinator Failure After PreCommit

This scenario demonstrates the non-blocking advantage. Suppose C successfully completes Phase 1 and Phase 2, but crashes before sending any DoCommit messages. All three participants are now in the PRECOMMITTED state, waiting for DoCommit, with timers running.

After their timeout expires, P1, P2, and P3 detect coordinator failure. They initiate the termination protocol by exchanging their states among themselves. P1 contacts P2 and P3 and learns both are PRECOMMITTED. According to the termination rule, if any participant is PRECOMMITTED, the transaction must have been unanimously voted YES, so it is safe to commit. All three participants independently transition to COMMITTED and apply their changes. No one remains blocked.

Contrast this with 2PC: in 2PC, participants would be stuck in the PREPARED state with no way to know if the coordinator had decided to commit or abort, forcing them to hold locks indefinitely until the coordinator recovers.

Scenario C: Participant Votes NO

If P2 had replied NO in Phase 1 (e.g., payment declined), C would immediately broadcast Abort(T1) to all participants. P1 and P3, which had voted YES and entered PREPARED, would transition to ABORTED upon receiving Abort, releasing their reserved inventory and shipping slots. Participants in PRECOMMITTED would never be reached, preserving the invariant that a PRECOMMITTED state implies unanimous YES votes.

Complexity Analysis

The performance of the three-phase commit protocol is characterized by its message complexity, latency, and resource requirements. While it solves the blocking problem, it does so at the cost of additional communication rounds compared to two-phase commit.

In the failure-free case, 3PC requires three rounds of messages: CanCommit/YES-NO, PreCommit/ACK, and DoCommit/ACK. For N participants, this results in 6N messages in total (counting both directions) and a latency of 3 network round-trips. Space complexity is modest, requiring only O(1) state per participant plus a durable log entry per state transition.

During failure recovery, the termination protocol adds additional overhead. Participants must exchange state information, which can require O(N^2) messages in the worst case if every participant queries every other participant. However, with a leader election optimization, this can be reduced to O(N).

Time complexity is dominated by network round-trips rather than computation. Each phase is O(1) in computational work per node, but O(N) in aggregate messages. The protocol is not suitable for high-throughput, low-latency transactions where 2PC or more modern protocols like Paxos-based commit might be preferred. The extra PreCommit round adds approximately 33% more latency compared to 2PC, which is the primary performance trade-off for non-blocking behavior.

Best, Average, and Worst Case Behavior

Best case occurs when no failures happen and the network is fast: exactly 3 RTTs and 3N log writes. Average case in a stable data center network is similar, with occasional timeouts due to GC pauses or transient slowness adding one extra RTT for retries. Worst case involves coordinator failure during PreCommit, triggering the termination protocol with leader election, state exchange, and potentially multiple timeout cycles, leading to O(N²) messages and significantly higher latency. Space remains O(1) per node in all cases, but the durable log grows linearly with the number of transactions.

Variations and Optimizations

While the classic three-phase commit protocol provides non-blocking guarantees under fail-stop assumptions, several variations and optimizations have been developed to improve its practicality and performance in real systems.

Quorum-Based 3PC and Paxos Commit

Traditional 3PC requires acknowledgments from all participants, making it vulnerable to a single slow node. Quorum-based variants require only a majority quorum to proceed from PreCommit to DoCommit. This improves availability and reduces tail latency. Paxos Commit, proposed by Jim Gray and Leslie Lamport, recasts the commit problem as a Paxos consensus instance, achieving non-blocking commit even under network partitions while maintaining the same message pattern as 3PC in the failure-free case. It replaces timeout-based failure detection with Paxos leader election.

Cooperative Termination Protocol

The naive termination protocol where every participant queries every other participant is expensive. An optimized cooperative termination protocol elects a new coordinator among the survivors using a bully or ring election algorithm. The elected coordinator collects states from a quorum and broadcasts the final decision. This reduces message complexity from O(N²) to O(N) and simplifies reasoning about correctness.

Read-Only and One-Phase Optimizations

If a participant knows its part of the transaction is read-only, it can vote YES and immediately be released after Phase 1, without needing to participate in PreCommit and DoCommit. Similarly, if there is only a single participant, the coordinator can collapse the protocol into a single-phase commit. These optimizations are widely used in databases to reduce overhead for common cases where transactions touch only one shard.

Timeout Tuning and Failure Detector Optimization

Performance of 3PC is highly sensitive to timeout values. Adaptive failure detectors that use phi-accrual detection rather than fixed timeouts can significantly reduce false positives while still detecting real failures quickly. Some systems use separate timeouts for each phase, with longer timeouts for CanCommit where participants may need to do disk I/O, and shorter timeouts for PreCommit and DoCommit which are primarily in-memory state transitions.

Three-Phase Commit with Backup Coordinator

To avoid the need for a full election during recovery, some implementations maintain a hot backup coordinator that synchronously replicates the coordinator's log. If the primary coordinator fails, the backup can immediately take over without an election. This is similar to the approach used in Spanner and other NewSQL systems, though they typically use Paxos for coordinator replication rather than pure 3PC.

Real-World Applications

Despite its theoretical limitations regarding network partitions, the three-phase commit protocol and its derivatives are used in several important real-world contexts, particularly where networks are relatively reliable and partitions are rare, such as within a single data center.

In distributed databases, 3PC is used for atomic commitment across shards. Systems like PostgreSQL's distributed extensions and MySQL Cluster have experimented with 3PC for cross-shard transactions. While many modern NewSQL systems have moved to Paxos or Raft for commit, the conceptual framework of 3PC — voting, pre-commit, and commit — remains central to their design.

Telecommunications and aerospace systems, where deterministic failure handling is critical, have historically used 3PC for replicated state machines controlling switches and flight systems. These environments often have tightly controlled networks with bounded delays, making the assumptions of 3PC realistic.

In microservices architectures, 3PC is sometimes used as a stronger alternative to the Saga pattern when true ACID semantics are required. For example, an order workflow involving inventory, payment, and fulfillment services can use 3PC to guarantee atomicity, whereas Sagas provide only eventual consistency through compensating transactions. However, due to latency concerns, many microservices opt for Sagas and accept eventual consistency.

It is important to recognize where 3PC is not used. In wide-area networks and public cloud environments where partitions are common, systems overwhelmingly choose Paxos, Raft, or Viewstamped Replication. These protocols provide the same non-blocking property as 3PC but also tolerate partitions, at the cost of requiring a majority quorum. Understanding this trade-off helps architects choose the right protocol for their network environment.

Comparison with Alternatives

Choosing an atomic commit protocol requires understanding the trade-offs between blocking behavior, partition tolerance, performance, and complexity. The three-phase commit protocol occupies a specific point in this design space.

The most direct comparison is between 2PC and 3PC. 3PC adds one extra phase and 2N messages to eliminate blocking, which is a worthwhile trade-off when availability is paramount and the network is reliable. However, if partitions are possible, neither 2PC nor 3PC is safe; Paxos commit should be used instead. Paxos commit essentially runs a Paxos instance to decide commit/abort, providing both non-blocking and partition-tolerant guarantees, but with higher implementation complexity.

The Saga pattern represents a fundamentally different approach. Instead of trying to achieve atomicity through a commit protocol, Sagas break a distributed transaction into a sequence of local transactions with compensating actions for rollback. This provides high availability and partition tolerance but sacrifices atomicity and isolation. Sagas are preferred for long-running business processes where holding locks across services for multiple round-trips would be impractical.

Common Mistakes and Best Practices

Implementing the three-phase commit protocol correctly is notoriously difficult. Subtle errors in logging, timeout handling, or state transitions can lead to violations of atomicity or liveness.

One of the most common mistakes is failing to log state transitions to stable storage before sending messages. If a participant replies YES to CanCommit but crashes before durably logging PREPARED, it may recover in the INIT state and incorrectly abort a transaction that other participants have already pre-committed. This violates atomicity. The rule is absolute: log before you send.

Another frequent pitfall is using inappropriate timeout values. Timeouts that are too short cause false failure suspicions, triggering unnecessary termination protocols and aborting transactions that could have committed. Timeouts that are too long increase blocking time and reduce availability. Best practice is to use adaptive timeouts based on observed network latency and to implement separate timeouts for each phase, accounting for the different amounts of work involved.

• Always use write-ahead logging: Every state change (PREPARED, PRECOMMITTED, COMMITTED, ABORTED) must be forced to disk before the corresponding ACK is sent. Use fsync or equivalent durable write primitives.
• Implement idempotent message handling: Network retries can cause duplicate PreCommit or DoCommit messages. Participants must handle duplicates gracefully by checking their current state and replying with the appropriate ACK without re-applying side effects.
• Do not assume partitions cannot happen: Even in a data center, partitions occur due to switch failures or misconfigurations. If partition tolerance is required, do not use pure 3PC; use Paxos or Raft instead. Clearly document the failure model your system assumes.
• Test failure injection thoroughly: Use chaos engineering tools to simulate coordinator crashes at each phase, participant crashes, message loss, and network delays. Verify that the termination protocol always reaches a consistent decision.
• Avoid holding locks too long: Participants hold locks from the moment they vote YES until they commit or abort. In 3PC, this duration is longer than in 2PC due to the extra phase. Minimize lock granularity and consider optimistic concurrency control to reduce contention.
• Handle coordinator recovery correctly: A recovering coordinator must read its log and, if it was in WAIT_FOR_PRECOMMIT_ACKS, run the termination protocol to determine whether to commit or abort. It must not unilaterally abort after having sent PreCommit to some participants.

Best Practice: Monitoring and Observability

Instrument each phase with metrics for latency, timeout rates, and abort rates. A sudden increase in PreCommit timeouts may indicate network degradation or an overloaded participant. Logging the full state machine transitions with transaction IDs enables post-mortem analysis of distributed transactions. In production, consider adding distributed tracing to correlate CanCommit, PreCommit, and DoCommit messages for a single transaction across services.

Interview Questions

Interview questions about the three-phase commit protocol often test understanding of distributed systems fundamentals, failure handling, and protocol trade-offs. Here are common questions with guidance on strong answers.

1. How does 3PC solve the blocking problem of 2PC, and what does it still not solve?

Answer: In 2PC, if the coordinator crashes after participants enter the PREPARED state, they are blocked indefinitely because they cannot know the global decision. 3PC adds a PreCommit phase that creates an intermediate state. The invariant is that if any participant is in PRECOMMITTED, all participants voted YES. Therefore, survivors can run a termination protocol: if any survivor is PRECOMMITTED or COMMITTED, they all commit; otherwise they abort. This makes 3PC non-blocking under fail-stop with bounded delays. However, it does not solve network partitions — if a partition separates participants, different sides could make conflicting decisions, violating atomicity. Paxos/Raft are needed for partition tolerance.

2. Walk through what happens if the coordinator crashes after sending PreCommit to only a subset of participants.

Answer: Suppose there are three participants P1, P2, P3. Coordinator sends PreCommit to P1 (which enters PRECOMMITTED and ACKs), then crashes before sending to P2 and P3 (which remain PREPARED). After timeout, participants run termination protocol and exchange states. They discover P1 is PRECOMMITTED. Since PRECOMMITTED implies all voted YES, the safe decision is to commit. All survivors will transition to COMMITTED. If instead the coordinator had crashed before sending any PreCommit, all survivors would be PREPARED and would correctly decide to abort. The key is that the presence of a single PRECOMMITTED state is sufficient to determine the global vote was unanimous.

3. What is the message and time complexity of 3PC, and when would you choose 2PC over 3PC?

Answer: 3PC requires 3 round-trips and 6N messages for N participants in the failure-free case, compared to 2 RTTs and 4N messages for 2PC. Time complexity is O(N) messages and O(1) computation per node, with space O(1) plus logging. I would choose 2PC over 3PC when latency is critical, blocking is acceptable due to fast coordinator recovery (e.g., coordinator is replicated via Paxos), or the system already has an external mechanism to handle blocking (like a transaction manager that recovers quickly). 3PC is preferred when non-blocking termination without external recovery is required and the network is reliable with bounded delays.

4. Why must participants log their state before sending acknowledgments?

Answer: Logging before sending ensures crash recovery is correct. If a participant sends YES without logging PREPARED and then crashes, it will recover in INIT and may abort, while other participants who received PreCommit will commit — violating atomicity. Similarly, a participant must log PRECOMMITTED before ACKing PreCommit; otherwise a crash and recovery could cause it to forget it was pre-committed and incorrectly abort. This is the write-ahead logging rule: the durable state must reflect the promise made to the coordinator before the promise is communicated.

5. Can 3PC guarantee both safety and liveness in an asynchronous network with partitions?

Answer: No, due to the FLP impossibility result and the CAP theorem. 3PC guarantees safety (atomicity) and liveness (non-blocking) only in a synchronous network with bounded delays and no partitions. In a fully asynchronous network where messages can be arbitrarily delayed and partitions can occur, it is impossible to guarantee both. If a partition occurs, 3PC can violate safety by allowing different partitions to decide differently. Modern partition-tolerant protocols like Paxos and Raft guarantee safety at the cost of liveness — they may block until a majority partition is available — which is the fundamental trade-off described by CAP.