Raft was designed with one goal in mind: understandability. Where Paxos forces you to reconstruct the full protocol from first principles before implementing anything, Raft decomposes the consensus problem into three relatively independent subproblems — leader election, log replication, and safety — each of which is much easier to reason about in isolation.

Leader Election

Every Raft cluster has exactly one leader at a time. Servers start as followers and listen for heartbeats from a leader. If a follower goes too long without a heartbeat, it becomes a candidate, increments its term, votes for itself, and sends RequestVote RPCs to the other servers.

A candidate wins if it receives votes from a majority. The key constraint: a server only votes for a candidate whose log is at least as up-to-date as its own. This single rule is what prevents stale nodes from winning elections and corrupting the cluster state.

Log Replication

Once a leader is elected, all writes go through it. The leader appends the entry to its own log and sends AppendEntries RPCs to followers in parallel. An entry is committed once a majority of servers have written it to their logs — at which point the leader applies it to its state machine and responds to the client.

This is where Raft’s clarity really shows. The log is the source of truth. If two logs have the same entry at the same index with the same term, they are guaranteed to be identical up to that point. Raft enforces this with a consistency check on every AppendEntries call.

Why It Matters

Consensus algorithms are the foundation of any system that needs to replicate state reliably — databases, distributed locks, coordination services. Understanding Raft at this level means you can reason about what happens during network partitions, node crashes, and split-brain scenarios without treating the system as a black box.

I’m implementing Raft from scratch in Go as part of the VizRaft experiment, with a real-time visualization of leader elections and log replication as they happen.