Fundamentals 8 min read

Two-Phase Commit, Paxos, and Raft: Core Concepts and Workflows

This article explains the principles and workflows of Two‑Phase Commit, Paxos, and Raft, detailing their roles, phases, failure handling, and how they achieve distributed consensus in fault‑tolerant systems, including the coordinator‑participant model, proposal numbering, leader election, heartbeat mechanisms, and log replication processes.

Architecture Digest
Architecture Digest
Architecture Digest
Two-Phase Commit, Paxos, and Raft: Core Concepts and Workflows

Two‑Phase Commit (2PC) ensures ACID properties across multiple nodes by using a single coordinator and multiple participants. It consists of a prepare phase where the coordinator asks participants whether they can commit, followed by a commit phase where the coordinator instructs participants to either commit or roll back based on the collected responses.

Potential issues include participant failures, mitigated by setting a timeout after which the transaction is considered failed, and coordinator failures, addressed by replicating the operation log to a standby coordinator that can take over.

Paxos

Paxos solves the consensus problem in a message‑passing distributed system where processes may be slow, killed, restarted, or messages may be delayed, lost, or duplicated. It defines three roles: Proposer (suggests a value), Acceptor (votes on proposals), and Learner (learns the chosen value).

Each proposal is a pair [n, v] where n is a unique, monotonically increasing sequence number and v is the proposed value. Acceptors record the highest‑numbered proposal they have seen and reject any proposal with a lower number.

When a proposer receives responses from a majority of acceptors, it can send an accept request. Learners observe that a majority of acceptors have accepted a proposal and thus learn the chosen value.

Raft

Raft simplifies consensus by introducing a leader elected among followers and candidates. Followers receive periodic heartbeat messages from the leader; if a follower does not receive a heartbeat within a random election timeout (typically 150‑300 ms), it becomes a candidate and starts an election.

The candidate requests votes from all other nodes. If it receives votes from a majority, it becomes the leader.

The leader then handles client modifications by appending them to its log, replicating the entries to followers, waiting for a majority of followers to acknowledge, and finally committing the entries so that all nodes agree on the state.

AlgorithmsRaftPaxosdistributed consensusTwo-Phase Commit
Architecture Digest
Written by

Architecture Digest

Focusing on Java backend development, covering application architecture from top-tier internet companies (high availability, high performance, high stability), big data, machine learning, Java architecture, and other popular fields.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.