In Module 13 you saw why a replicated system needs exactly one leader, and how badly things go when two nodes both think they're in charge. You also saw that "the node with the lowest ID wins" doesn't work once the network can split. This lesson opens up the algorithm most modern systems use to pick that leader safely: Raft.
Raft was published in 2014 by Diego Ongaro and John Ousterhout, with an unusual goal for a consensus algorithm: to be understandable. It splits the problem into two parts. This lesson covers the first, leader election. The next covers log replication.
Tiffin's example: its configuration store (surge multipliers, which cities are open, feature flags) runs on a 5-node etcd cluster, which uses Raft. If the leader dies at 8:15pm, a new one must take over within a second or two, and there must never be two.
Three states and a term number
Every Raft node is always in one of three states:
| State | What it does |
|---|---|
| Follower | Passive. Responds to the leader and to candidates. Waits for heartbeats |
| Candidate | Trying to become leader. Asks everyone for votes |
| Leader | Handles all client requests. Sends heartbeats to keep followers quiet |
Time is divided into terms, numbered 1, 2, 3 and so on. Each term starts with an election. If someone wins, they lead for the rest of the term. If nobody wins, the term ends with no leader and a new term begins.
A term is Raft's logical clock. Every message carries the sender's term. A node that sees a higher term than its own immediately adopts it and becomes a follower. A message with a lower term is rejected as stale.
That rule is what kills "two leaders". An old leader that was cut off and comes back still thinks it's in term 3. The first reply it gets says "term 4", and it steps down on the spot.