Raft Consensus: Leader Election Without the PhD

Multiple servers. Network partitions. Crashes mid-write. How does anyone agree on what happened? Consensus algorithms answer that — and Raft made it teachable.

The problem

Replicated state machines: every node runs the same commands in the same order. If leader says "set x=5" then "set x=7", all followers must apply both — identically.

Raft roles

• Leader — accepts client writes, replicates log entries
• Followers — passive, respond to leader heartbeats
• Candidate — temporary state during elections

Only the leader handles writes. One writer eliminates conflicts.

Leader election

Time divided into terms (monotonic counters):

1. Follower misses heartbeat → becomes candidate
2. Candidate votes for itself, requests votes from peers
3. Majority wins → new leader; minority revert to follower

// Simplified election trigger
if time.Since(lastHeartbeat) > electionTimeout {
    becomeCandidate()
    currentTerm++
    requestVotes()
}

Randomized election timeouts reduce split-vote storms.

Log replication

Client sends command to leader. Leader:

1. Appends to local log
2. Replicates to followers (parallel RPC)
3. Commits once majority acknowledges
4. Applies to state machine, responds to client

Followers never commit uncommitted entries — consistency over availability during partitions.

vs Paxos

Paxos is proven minimal but notoriously opaque. Raft sacrifices some generality for understandability — same safety guarantees, clearer decomposition.

[!NOTE] etcd, Consul, and CockroachDB all use Raft variants in production.

Failure modes

Takeaway

Raft is the algorithm you reach for when one database isn't enough. Terms, votes, and append-entries RPCs — boring on purpose, reliable by design.