How Raft Elects a Leader and Replicates Logs: Step-by-Step Walkthrough

Raft Election Process

Leader Election

In a Raft cluster with members A, B, and C, all start as Followers. Their heartbeat timeouts are 110 ms (A), 150 ms (B), and 130 ms (C). Since there is no Leader, each member does not receive heartbeats.

Member A has the shortest timeout, becomes a Candidate, increments its term to 1, and broadcasts a RequestVote message.

RequestVote includes A's term and latest log index. Members B and C apply the voting rules:

Members with a larger term reject votes for smaller‑term candidates.

Members with a larger log index reject votes for smaller‑index candidates.

Only one vote per term is granted, following a first‑come‑first‑served principle.

Because B and C have smaller terms and no larger log index, they vote for A. A receives three votes (including its own), becomes Leader, and sends heartbeats.

If A does not obtain a majority within the election timeout, it resets its timeout and the election proceeds in the order A → C → B. Network issues may trigger additional election rounds.

Log Replication

Log replication is a single‑phase negotiation where the AppendEntries message carries the log entries and the Leader's committedIndex. Followers compare the Leader's committedIndex to advance their own commits.

Steps:

Leader appends the client’s Add command as a log entry with index 1.

Leader sends AppendEntries(0, <1, Add>) to Followers, where the first parameter is committedIndex, the second is the log index, and the third is the client command.

Followers append the entry locally.

Followers ACK the entry; upon receiving a majority of ACKs, the Leader commits the entry and returns the result to the client.

Followers later commit the entry when they receive a heartbeat containing committedIndex = 1.

Log Alignment

Using <term, logIndex> to represent a log entry, inconsistencies can arise when Followers have higher log indices than the Leader (e.g., Follower E at index 3, Follower D at index 4). This occurs if those Followers were previously Leaders and crashed after appending entries.

Alignment steps (illustrated with Follower E):

Leader sets nextIndex = lastLogIndex + 1 = 7.

Leader sends a probe AppendEntries with preLogIndex = 6 and preLogTerm = 3.

Follower replies failure, reporting lastLogIndex = 3.

Leader updates nextIndex = 4.

Leader probes again with preLogIndex = 3, preLogTerm = 2; follower again fails, reporting lastLogIndex = 3.

Leader adjusts nextIndex down to 3.

Leader probes with preLogIndex = 2, preLogTerm = 1; follower succeeds.

Leader sends the missing log entry (index = 3) via AppendEntries.

Follower overwrites its local entry, acknowledges success.

Leader increments nextIndex and continues until the follower’s log matches the Leader’s.

After alignment, the follower’s log is consistent with the leader.

Note: This excerpt is adapted from the book "Deep Understanding of Distributed Consensus Algorithms" (ISBN 978‑7‑302‑63003‑6) published by Tsinghua University Press.