How Raft Guarantees Strong Consistency: Leader Election & Log Replication Explained

Raft Overview

Raft is a consensus algorithm for managing a replicated log. It achieves the same results and efficiency as Multi‑Paxos but with a more understandable design, separating leader election, log replication and safety into a strong‑leader model.

Raft separates leader election, log replication and safety, enforcing a strong‑leader model so followers only need to consider the leader’s state.

It provides a single‑node configuration change mechanism to avoid split‑brain situations.

Raft Node States

Follower : receives leader messages, maintains heartbeat, may become candidate if leader times out.

Candidate : requests votes from other nodes; if it receives a majority, it becomes the leader.

Leader : handles all client writes, replicates log entries to followers, and sends periodic heartbeats.

Further Reading

Etcd: https://etcd.io/docs/v3.4.0/

Consul: https://www.consul.io/docs

Raft open‑source overview: https://raft.github.io/

Raft learning guide: http://thesecretlivesofdata.com/raft/

Core Raft Mechanics

Strong Leader Election

Election Elements

Term: each election increments the term number.

Timeout: includes leader heartbeat timeout and candidate election timeout.

Election Process

Initialization: all nodes start as followers with term 0 and a random election timeout.

Vote Request: a follower whose heartbeat expires becomes a candidate, increments its term, and sends RequestVote RPCs to other nodes.

Vote Response: if a candidate receives votes from a majority, it becomes leader; otherwise it retries after a new timeout.

Log Replication

Log Entry

Log entry attributes

Command (cmd) : the client operation that the leader persists to its state machine.

Log index (logIndex) : a monotonically increasing integer that uniquely identifies the entry.

Term : the term of the leader that created the entry, used for consistency checks.

Replication Principle

When a client issues a write (e.g., set x=10 ), the leader appends the command to its log and sends an AppendEntries RPC to followers. Once a majority acknowledge the entry, the leader applies it to its state machine and returns the result to the client.

Consistency Check

If a follower’s log diverges from the leader’s, the leader identifies the last matching index and forces the follower to overwrite conflicting entries, ensuring all nodes have identical logs.

Member Changes

Raft uses a single‑node configuration change protocol to add or remove servers without causing split‑brain. The leader updates the cluster configuration, synchronizes logs to the new node, and replicates the updated configuration to the rest of the cluster.

Term and Election Rules

Each term is a monotonically increasing integer.

Followers become candidates when they do not receive a heartbeat within their timeout.

A candidate wins the election if it receives votes from a majority of nodes.

Leaders send periodic heartbeats containing the current term to prevent new elections.

Summary

Raft achieves strong consistency by electing a single leader, replicating client commands as log entries, and enforcing consistency checks during replication and configuration changes. Its term‑based election, heartbeat mechanism, and single‑node configuration updates ensure the cluster remains available and avoids split‑brain scenarios.