Distributed consensus, replication, and fault tolerance / personal lessonsLesson 8 of 17
Lesson browserDistributed consensus, replication, and fault tolerance lessonsPrevious: Consensus, safety, and the limits of progressNext: Raft log repair and commitment
Distributed systems · Lesson 8

Raft elections and persistent terms

Follow votes, terms, split elections, and the log freshness restriction.

By the end: Explain what prevents two winners in one term and why that alone is insufficient.

Turn a suspicion into an election

Raft servers are followers, candidates, or leaders. A follower that times out without appropriate leader contact can become a candidate. It increments its term, votes for itself, persists that state, and asks peers for votes. A term is a monotonically increasing logical election epoch, not a wall-clock interval. Several elections may fail before a leader is elected.

A server grants at most one candidate its vote in a term. The current term and vote must survive a crash before the reply is sent. A candidate wins with a majority. Because majorities intersect, two candidates cannot both win in the same term if every voter respects that persistent rule. Split votes are possible; randomized timeouts reduce the likelihood of repeatedly splitting, without making progress unconditional.

Persist the election attempt before asking others to rely on it

A Raft server keeps a current election term even when its log has not changed. Suppose a follower's current term is 8 and its last log entry was created in term 6. On starting an election, it moves to term 9, records a vote for itself in term 9, and requests votes. Its last-entry term remains 6. Starting an election does not relabel old entries or prove that the candidate possesses a more recent history.

Persisting the term and vote means making the state recoverable before sending a response that other servers may count. Consider a voter that records its vote only in memory, replies, then crashes. A candidate may already have used that reply to declare an election victory. If recovery forgets the vote, the voter can grant another candidate a vote in the same term. The problem is the order of durable recording and external reliance, even if the disk eventually receives the record during ordinary runs.

For a separate five-member paper election, let A receive votes from A, B, and C. Let D seek votes from C, D, and E in the same term. Both sets contain three identities, but C belongs to both. If C durably granted A its vote, it cannot grant D a different vote in that term. Repeated messages requesting A's existing vote do not create a new vote for another candidate. Repeated responses from B likewise do not count as extra members.

This proof establishes election safety within one term, not perpetual leadership of the winner. In the next term C may vote for another eligible candidate. It also does not guarantee that anyone wins the present term. A and D can each receive two votes while C's response is unavailable. Both candidates then lack the required third vote. The system needs another attempt rather than a rule that treats the largest observed minority as sufficient authority.

Randomized timeouts help by making repeated simultaneous attempts less likely. In a constructed schedule, A times out first and its vote requests reach peers before their own deadlines. Eligible followers can vote for A, allowing it to gather a majority. In a contrasting schedule, several candidates start before hearing from one another and split the votes. These are timing cases, not fixed duration requirements. Safety cannot depend on candidates always choosing sufficiently different random delays.

Durability here covers the stated crash-recovery model. If a server loses its storage and returns under its old identity with an empty term and vote record, it no longer satisfies that assumption. Restoring an identity is not equivalent to restarting a process that remembers its obligations. Later recovery procedures must handle replacement deliberately. An election proof cannot repair forgotten state by counting the same server name as though the old durable promise still existed.

A newer term is not a globally instantaneous switch

Servers learn new terms through messages. On encountering a higher term in the relevant protocol messages, a server updates its term and steps down as required. An isolated old leader may still believe it leads term 4 while a majority elects a leader for term 5. Raft does not promise that all machines always believe in the same leader at the same instant.

The safety requirement is that these beliefs cannot produce incompatible committed histories. The old leader cannot obtain a current quorum from servers that have moved on and reject its stale term. It may still receive client requests or attempt external side effects. The reads and fencing lesson explains why local leadership belief is not sufficient authorization to answer every request or modify an unrelated storage system.

Follow terms through a partition without inventing a global switch

Use a separate paper timeline with A as leader in term 4 and B and C as followers. A loses communication with both peers but remains connected to a client. B eventually starts term 5. If C grants B a vote and B has its self-vote, B obtains a majority of this three-member configuration. No message announcing this outcome has reached A. A's local term can remain 4 without violating Raft's rule that terms never decrease at an individual server.

There are now two local leader beliefs, but not two winners of the same term. A won term 4 and B won term 5. The election-safety argument did not forbid that situation. The relevant question is what actions each can complete. B and C cannot generate successful replies to new term-4 append requests once they have advanced to term 5. On learning the higher term through the protocol, A updates its own term and stops acting as the old leader.

A must not reinterpret a delayed acknowledgment for an earlier append as approval of a different later entry. Responses provide evidence about specific requests and log positions under particular terms. Suppose A received confirmation through index 7 before isolation and then appends index 8 locally. Its old confirmation through 7 does not establish replication of 8. The replication lesson's distinction between stored entries and received evidence continues to apply when messages from earlier leadership attempts remain in transit.

Client requests can still arrive at A because client routing and cluster authority are different mechanisms. A process being reachable, serving an HTTP connection, or holding an old leader label does not establish that its current state is authoritative. It might accept a request into its local uncommitted log, but it cannot promise the same durability as a correctly committed operation merely because the process has not crashed. The next lesson identifies the extra rules needed to protect committed history.

Reads need a further distinction. A's local application state might be fully applied through everything it once knew was committed, yet miss a newer write committed by B. Conversely, a server with current authority can have an application state machine that has not caught up to its known committed log. A linearizable read needs both appropriate current authority and sufficient applied state. The later read lesson develops that protocol. Election victory alone settles neither requirement indefinitely.

External resources do not necessarily understand Raft terms. A paused worker associated with A could resume and send an old file write even after B's election. Unless the resource checks an appropriate authority token atomically with its write, the vote rules do not stop that external action. This is why the course later introduces resource-enforced fencing. Within these election examples, restrict the safety claim to the Raft protocol state rather than assuming every connected service automatically obeys its authority changes.

Work through the model

Which logs permit a vote?

Fixed membership A,B,C,D. Candidate D runs in election term 5 and votes for itself. All other voters are in term 5 with no prior vote. Only the log-freshness check varies here; messages arrive and votes persist. A new preset starts a separate hypothetical election, not a second vote in the same execution.

D's last entry: term 3, index 10. The entry term is distinct from election term 5.

Voter A

Last term 4
Last index 6

Reject: log too old

Voter B

Last term 3
Last index 9

Grant: fresh enough

Voter C

Last term 4
Last index 5

Reject: log too old

2 votes including D; majority is 3. D cannot win with these responses.

A longer log can lose the check. Compare last-entry terms first, then indexes only if terms tie. Other real elections may also be blocked by prior votes, newer terms, or missing messages.
Candidate last term,indexVoter last term,indexFreshness check
4,63,9Pass: later last term
3,104,6Fail: older last term
4,54,6Fail: same term, shorter log
4,64,6Pass: equal freshness
Passing freshness is necessary but not sufficient: the voter must also permit that term and vote.

Read the hypothetical votes as independent cases

The election control fixes four members, A through D, and a majority of three. D is the candidate in election term 5. Each other voter is already in term 5 and has not granted a vote. These assumptions remove stale request terms, prior votes, missing messages, and lost persistence from the calculation. The display isolates log freshness. Passing the displayed check means that a vote is allowed under these fixed conditions, not that arbitrary real election requests always receive a vote.

Select Longer, older term. D's last entry has term 3 and index 10. Voter A ends in term 4 at index 6, so A rejects D. Voter B ends in term 3 at index 9, so the equal entry terms let the longer index 10 pass. Voter C ends in term 4 at index 5, so C also rejects D. D has its self-vote and B's vote, only two of four. Ten entries do not compensate for the older last-entry term.

Next select Shorter, newer term as a new hypothetical election. D ends in term 4 at index 5. A has the same last-entry term but ends at index 6, so A rejects D. B's last-entry term is 3, so B grants despite having a larger last index. C has exactly the same last term and index as D and grants. Including D's self-vote gives three votes. The result follows from term-first comparison, not from total log length.

Finally select Matches freshest voter. D ends in term 4 at index 6. A now passes the equality check, B passes the newer-entry-term comparison, and C passes the equal-term longer-index comparison. D receives four votes including its own. Every preset still uses election term 5. The words newer term in the preset name concern D's final log entry relative to some voters, not a change in the candidate's election term.

Switching presets replaces the hypothetical case. It does not allow B to cast several different votes in one execution, rewrite D's real log, or restart a simulated network. The accompanying evidence table also lists generic pairwise comparisons rather than additional hidden voters. Neither display verifies complete log prefixes. Its pairs are inputs to the freshness comparison whose safety role depends on the log-matching and commitment rules taught in the next lesson.

For a paper variation, keep D's final pair at term 4, index 6 but assume A already voted for another candidate in election term 5. A must refuse D even though freshness passes. If C is also unreachable, D can receive only its own vote and B's. This variation is not a control setting. It demonstrates why a successful freshness test is necessary but not sufficient for a real election victory, and why the widget states its other assumptions explicitly.

Protect history when selecting a leader

One vote per term prevents two winners within a term, but does not stop a later winner from lacking earlier committed entries. Raft therefore checks the candidate’s log before granting a vote. Compare the last entry’s term first. A later last-entry term is more up-to-date. Only when those terms are equal do you compare the last index. The candidate must be at least as up-to-date as the voter.

A log ending at term 4, index 6 is more up-to-date than one ending at term 3, index 9. This is not a universal rule for “newest data”; it works with Raft’s prefix and commitment invariants. The full leader-completeness argument couples this voting rule to log replication and the current-term commitment rule in the next lesson. Never replace the check with “the longest log wins.”

Understand what freshness contributes to preserving history

Why compare the term of an entry before its index? A higher entry term records that some leader in a later election epoch created that entry. Under Raft's full rules, such entries carry constraints from how that leader could have been elected and how it replicated its prefix. Index alone records only position. A deposed leader may have appended many uncommitted commands during isolation. The number of such commands cannot give that leader a right to remove an already committed decision.

Consider a separate paper case with a common committed prefix through index 4. A later appends uncommitted entries through index 12 while isolated. Another leader, elected through the proper rules, has a log ending at index 6 with a higher last-entry term. Comparing lengths alone would prefer A's speculative suffix. Raft instead compares the entry terms first. This is an explanation of why length is inadequate, not a complete proof that every possible higher-term log contains every committed entry.

The proof obligation combines elections with replication. A future leader must include earlier committed entries. Quorum intersection ensures that its election voters overlap a quorum involved in a prior commitment, but the overlap only helps if the voter refuses a candidate whose history is insufficient. Freshness supplies a refusal rule. Prefix matching and the current-term commitment restriction supply the remaining relationships between a fresh final entry and the history before it. The next lesson develops those relationships explicitly.

One subtle consequence is that freshness does not mean the candidate knows the exact committed boundary. A candidate might possess an entry that was committed elsewhere without having received the old leader's commit notification. Its log can be eligible while its local commit knowledge remains incomplete. Election does not authorize applying every entry simply because it survived on the candidate. The new leader must establish commitment under the appropriate rules before application and before promising results that depend on it.

Another consequence is that losing an election does not prove a server's stored commands are invalid application requests. A rejected candidate may hold perfectly sensible commands that never obtained a protected place in the log. Some can later be overwritten. Clients waiting on them have an unknown outcome until the service resolves their operation identities through its documented protocol. Retrying with a fresh identity can duplicate work if an original command eventually survives and executes. The retry lesson treats that application boundary separately.

To audit an election claim, identify which term is being discussed, which distinct members supplied votes, and what persistent state constrains those voters. Then inspect the candidate's final entry term and index rather than substituting its current election term for the entry term. Finally ask which replication rule connects election eligibility to committed history. This sequence separates the small same-term uniqueness proof from the stronger leader-completeness property, which requires the combined Raft protocol rather than an election tally alone.

Exercises

A forgotten vote

B votes for A in term 7, crashes, forgets the vote, then votes for C in term 7. In a three-node cluster, what could happen?

Hint

Count each candidate’s self-vote plus B.

Worked answer
CandidateVotesCount
AA and B before crash2 of 3
CC and B after crash2 of 3
The shared voter must preserve its promise across recovery.

A could win with A+B and C could win with B+C in the same term. The intersection B did not enforce the promised restriction after restarting. Persisting currentTerm and votedFor before responding closes this failure case.

The longer candidate log

A candidate ends at term 5,index 8. A voter ends at term 6,index 4. Should the voter pass the log-freshness check?

Hint

Compare last-entry terms before lengths.

Worked answer
ComparisonCandidateVoterDecision
Last term56Candidate is older
Last index84Not used to override term
Length is the tiebreaker only when last terms are equal.

No. Term 5 is older than term 6, even though index 8 is larger. A server that instead compares only lengths can elect a candidate that lacks the required history. This is specifically Raft’s ordering of log freshness.

Sources and further reading

The explanations and worked answers above stand alone. These references provide the original algorithms, assumptions, and deeper proofs; they are not required downloads.

Lesson browserDistributed consensus, replication, and fault tolerance lessonsPrevious: Consensus, safety, and the limits of progressNext: Raft log repair and commitment