Understanding Raft: A Simple Guide to Distributed Consensus

The most famous distributed consistency algorithm is Paxos, proposed in 1990 and used by Google’s Chubby lock service. Subsequent algorithms, such as ZooKeeper’s ZAB, are variations of Paxos, but Paxos is often regarded as complex and hard to understand.

In 2013, two researchers at Stanford designed Raft with simplicity in mind. Raft is now widely adopted; notable examples include etcd and the service‑discovery component of Google’s Kubernetes.

What is distributed consistency?

In a single‑node environment, a client sends a value to a node and consensus is trivial. When multiple nodes are involved, achieving consistency becomes a challenge.

Raft is designed to solve this distributed consistency problem.

Raft’s approach

Each node can be in one of three states:

Follower

Candidate

Leader

All nodes start as followers.

If a follower does not receive a heartbeat from a leader, it becomes a candidate and requests votes from other nodes to become the leader.

When a candidate receives votes from a majority of nodes, it becomes the leader. All subsequent modifications to the system must go through the leader.

For example, a client sends a request to the leader, which records the operation in its log (without immediately changing the node’s state).

The leader then replicates this log entry to all followers, which store it in their own logs.

Followers acknowledge receipt, and once the leader receives acknowledgments from a majority, it commits the entry, finally updating the state of the nodes.

After committing, the leader notifies followers that they can apply the update, achieving a consistent system state.

This process is called log replication, a core component of Raft, alongside leader election.

For an interactive demonstration of Raft, visit: http://thesecretlivesofdata.com/raft/

A comprehensive Chinese Raft documentation is available at: https://github.com/maemual/raft-zh_cn/blob/master/raft-zh_cn.md