Raft — design and leader election.

Diego Ongaro and John Ousterhout's 2014 paper, "In Search of an Understandable Consensus Algorithm," states its goal in the title — and delivers on it by making one explicit, deliberate design choice that Paxos's own presentation never made: decompose the problem into independently-understandable pieces (leader election, log replication, safety, membership changes) instead of presenting consensus as one dense, interleaved proof. This article covers Raft's design philosophy and the first piece — leader election, built entirely from vocabulary this series has already handed you (terms are proposal numbers/view numbers under a third name; the election safety argument is, once again, article 3.3's majority overlap). Article 5.6 continues with log replication and the full safety proof.

Raft's explicit design goal: understandability as a first-class metric

Ongaro and Ousterhout's paper makes an unusual, explicit methodological claim for a systems paper: they treat understandability as a design goal to be optimized directly, alongside the usual correctness and performance metrics — and they back this claim with an actual user study, teaching both Raft and Paxos to students and measuring comprehension. This framing directly continues the thread articles 5.1 and 5.4 have been building: Paxos's allegorical presentation delayed adoption for years; VR's thesis-format obscurity limited its reach despite solid engineering; Raft's authors treat this history as a solvable design problem, not an unavoidable cost of correctness. The result of that explicit focus is decomposition: rather than Paxos's tightly-coupled Phase 1/Phase 2 mechanism (where election and value-agreement are, in the original presentation, somewhat entangled), Raft splits the problem into clearly separated sub-problems that can be understood, and largely verified, independently.

Terms: Raft's name for the leadership-epoch counter

Raft divides time into terms, numbered consecutively — precisely the same concept as Multi-Paxos's proposal numbers (article 5.3) and VR's view numbers (article 5.4), a third independent name for the identical underlying mechanism this series keeps re-encountering. Each term begins with an election; if an election succeeds, exactly one leader serves for the remainder of that term; if it fails (article 4.2's split-vote scenario), the term ends without a leader and a new term begins. Every message in Raft carries the sender's current term number, and a simple, universal rule keeps everyone converging: if a node ever sees a term number higher than its own, it immediately updates to that higher term and, if it was a leader or candidate, steps down to follower. This one rule is what makes stale leaders (from article 3.4's stale-read discussion) reliably discover they've been superseded.

The three node states

Every Raft node is, at any moment, in exactly one of three states:

• Follower — the default, passive state. Followers accept log entries and RPCs from a leader, and vote in elections, but never initiate anything themselves.
• Candidate — a follower transitions here when its election timeout (article 4.2's randomized timeout) expires without hearing from a leader; it then requests votes from peers, attempting to become leader.
• Leader — a candidate that wins a majority of votes becomes leader for the current term, and handles all client requests and log replication (article 5.6) until it steps down or is superseded.

The election protocol: RequestVote

When a follower's election timeout expires, it becomes a candidate: increments its current term, votes for itself, and sends a RequestVote(term, candidateId, lastLogIndex, lastLogTerm) RPC to every other node. Each recipient grants its vote if — and only if — both of these hold: (1) it hasn't already voted for a different candidate in this term (a node votes at most once per term, "first come, first served" — this alone is enough to prevent two candidates both winning a full majority in the same term, since two disjoint majorities are impossible per article 3.3), and (2) the candidate's log is at least as up-to-date as the voter's own — comparing lastLogTerm first, then lastLogIndex as a tiebreaker (exactly the "vote only for a candidate whose log is at least as current" rule previewed back in articles 3.3 and 4.2, now given its precise, concrete comparison criteria).

On election timeout, a follower becomes a Candidate:
  currentTerm += 1
  votedFor = self
  send RequestVote(currentTerm, self, lastLogIndex, lastLogTerm) to all peers

On receiving RequestVote(term, candidateId, lastLogIndex, lastLogTerm):
  if term < currentTerm:                 reject   (stale candidate)
  if term > currentTerm:                 currentTerm = term; step down to follower; votedFor = null
  if votedFor is null or votedFor == candidateId:
      if candidate's log is at least as up-to-date as mine:
          votedFor = candidateId
          grant vote
      else:
          reject   (my log is more current -- I might hold a committed entry they lack)
  else:
      reject   (already voted for someone else this term)

If the candidate receives votes from a majority of nodes (article 3.3, doing its work under yet another name), it becomes leader immediately and starts sending heartbeats (empty AppendEntries RPCs, covered fully in article 5.6) to establish authority and reset every follower's election timeout, preventing unnecessary further elections.

Why the log up-to-dateness check is the whole safety mechanism, made concrete

This is worth connecting explicitly back to article 3.3's leader-election application and article 5.2's Paxos Phase 1 rule, because it's the identical mechanism appearing a third time, now fully concrete: any candidate that wins a majority vote is guaranteed, by article 3.3's overlap proof, to have gotten at least one vote from a node that also participated in whatever majority most recently committed an entry (article 3.2's precise definition of "committed"). That overlapping voter would have refused to vote for a candidate whose log doesn't include that committed entry — so any candidate that actually wins must already have it. This is exactly why Raft never needs a separate "sync the new leader's missing committed data" step before it starts serving — the election protocol's voting rule structurally guarantees the new leader already has everything it needs, before it's even elected.

FAQ

Takeaways

• Raft's explicit, stated design goal is understandability, pursued via decomposition into independently-graspable sub-problems: leader election (this article), log replication and safety (5.6), and membership changes (Phase 9.6).
• Terms are Raft's name for the leadership-epoch counter — functionally identical to Multi-Paxos's proposal numbers (5.3) and VR's view numbers (5.4), the same mechanism under a third name.
• Every node is Follower, Candidate, or Leader; the "step down on seeing a higher term" rule keeps the system converging reliably.
• The RequestVote protocol grants a vote only if the node hasn't already voted this term and the candidate's log is at least as up-to-date — the concrete implementation of the log-comparison voting rule previewed all the way back in articles 3.3 and 4.2.
• This voting rule, combined with majority overlap (3.3), guarantees any elected leader already holds every committed entry — no separate catch-up step needed before serving, exactly the same safety payoff Paxos's Phase 1 and VR's view change deliver, via a third independently-arrived-at mechanism.
• Article 5.6 continues with log replication (AppendEntries) and Raft's full, formal safety proof.

References & further reading

• Ongaro & Ousterhout — In Search of an Understandable Consensus Algorithm (2014) — the primary source; Section 5.2 covers leader election in full.
• The Raft Consensus Algorithm (raft.github.io) — includes the visualization tool referenced widely for building intuition about elections and log replication.
• cvam.sight — Consensus 4.2: Leader Election — the general framework this article's RequestVote protocol makes concrete.
• cvam.sight — Consensus 5.4: Viewstamped Replication — the closely parallel view-change mechanism.