Raft — Understandable Consensus

Takeaway

Raft decomposes consensus into leader election, log replication, and safety; its design emphasizes understandability without sacrificing performance.

The problem (before → after)

Before: Paxos is correct but hard to implement.
After: Raft provides a practical protocol with clear roles and invariants.

Mental model first

A class president (leader) is elected by majority; they propose assignments (log entries) and ensure everyone writes them in the same order; if they fail, a new election is held.

Just-in-time concepts

Terms and voting; election timeouts.
Log matching: same index/term implies identical prefix.
Commit rules: entry is committed once stored on a majority and leader’s term.

First-pass solution

Followers start elections on timeout; candidates request votes; leader appends entries and sends AppendEntries RPCs; followers reject inconsistencies; leader backs up.

Snapshotting truncates logs; install snapshot RPC.
Cluster membership changes with joint consensus.
Linearizable reads via leader lease or read-index.

Principles, not prescriptions

Strong leader simplifies reasoning and performance.
Preserve safety invariants across elections.

Common pitfalls

Mismanaging timeouts causing split votes.
Incomplete log consistency checks.

Connections and contrasts

See also: [/blog/consensus-paxos], [/blog/byzantine-fault-tolerance], [/blog/cap-theorem].

Quick checks

Why leader-based? — Simplifies replication and ordering.
When is an entry committed? — On majority and leader’s term.
How to reconfigure? — Joint consensus phase.