Raft elections need a majority of voters

Tue, 21 Sep 2027 00:00:00 +0000

Raft leader elections require a strict majority of the configured voting members. With fixed membership and one durable vote per server per term, two candidates cannot both win the same term: their majorities would overlap at a voter that cannot support both. This is an election guarantee, not a claim that every node always agrees about the current leader.

One leader per term

Count the configured voters, not just reachable machines. Five voters require three votes even when only two can communicate. Learners and non-voting replicas do not automatically enlarge that denominator. Membership changes require their own safe protocol; independently replacing the voter list in each partition defeats the intersection argument.

The vote-once rule matters as much as the arithmetic. A server must retain its current term and vote across crashes before acknowledging them. Repeating a response from one voter does not produce extra votes. Authentication and correct membership identity are also assumed; this crash-fault model does not establish protection against malicious voters inventing messages.

Authority differs from local belief

A majority partition can elect a leader in a newer term while an isolated old leader still believes it leads the earlier term. Basic Raft steps down when it learns of a higher term; immediate resignation merely because heartbeats receive no replies is not the universal rule. Implementations may add quorum checking, but that is a separate mechanism.

The minority cannot commit new client commands by itself. Election restrictions, log matching, and commitment rules work together to protect replicated state across terms. A majority count alone does not make arbitrary external writes safe. A worker acting on a previously granted leadership belief may need resource-side fencing, and linearizable reads need the protocol’s current-authority checks rather than trust in a local leader flag.

Terms and timers have different jobs

A term is a logical epoch of arbitrary length, not a fixed-duration lease. Heartbeats normally prevent followers from starting elections while they hear from a valid leader. Missing them triggers suspicion and a later election; it does not prove the old machine stopped executing. Raft’s safety argument does not depend on synchronized wall clocks.

Randomized election timeouts help competing candidates avoid repeatedly splitting votes. Timely communication and sufficient processing capacity are still needed for progress. Overloaded machines, packet delays, and aggressive timeouts can cause election churn even without a permanent partition. Tune from observed latency and scheduling behavior, not an assumption that a shorter timeout is always better.

When it breaks

Four voters require three votes and cannot progress after a two-versus-two split. Three and four voters both tolerate one unavailable voter; adding a fourth does not buy a second failure. Five voters tolerate two. Odd sizes improve this particular capacity tradeoff, but even sizes still retain the same quorum-intersection safety property.

A minority may receive or buffer a request, but must not report a new uncommitted command as successfully committed. Client timeouts also leave uncertainty about whether a command committed elsewhere. Retrying safely therefore depends on the application contract, including request deduplication where needed, rather than assuming every unavailable response proves no effect occurred.

A candidate also needs a sufficiently up-to-date log. In Raft, voters compare the last log term and then its index, rather than simply choosing the longest log. Removing this restriction can violate leader completeness even when the candidate collects a numerical majority. The ballot exercise deliberately omits this log rule and cannot validate a consensus implementation.

Three of five, in one term. Source-based mechanism illustration. Model values and source-reported observations are not a new runtime test.

Check it quickly

Save this as majority.py and run python3 majority.py. It uses a shared in-memory ballot box, fixed voter identities, and explicit terms. Repeated messages are deduplicated. It performs no network operations or durable writes.

def quorum(size):
 if size < 1:
 raise ValueError("at least one voter is required")
 return size // 2 + 1


class Ballots:
 """Fixed membership, unique votes, and in-memory per-term voting only."""
 def __init__(self, size):
 self.size = size
 quorum(size)
 self.terms = [0] * size
 self.voted_for = [None] * size

 def elect(self, candidate, term, reachable):
 nodes = sorted(set(reachable))
 if not 0 <= candidate < self.size or term < 1:
 raise ValueError("invalid candidate or term")
 if any(not 0 <= node < self.size for node in nodes):
 raise ValueError("unknown voter")
 votes = []
 for node in nodes:
 if term < self.terms[node]:
 continue
 if term > self.terms[node]:
 self.terms[node] = term
 self.voted_for[node] = None
 if self.voted_for[node] in (None, candidate):
 self.voted_for[node] = candidate
 votes.append(node)
 return len(votes) >= quorum(self.size), votes


assert [quorum(n) for n in (3, 4, 5)] == [2, 3, 3]
cluster = Ballots(5)
assert cluster.elect(0, 1, [0, 1, 2]) == (True, [0, 1, 2])
assert cluster.elect(3, 1, [3, 4]) == (False, [3, 4])
assert cluster.elect(3, 1, range(5)) == (False, [3, 4])
assert cluster.elect(0, 1, [0, 1, 2]) == (True, [0, 1, 2])
print("one winner per term; repeated same-candidate requests preserve votes")

assert cluster.elect(3, 2, range(5)) == (True, list(range(5)))
assert cluster.elect(0, 1, range(5)) == (False, [])
print("a newer term can elect another candidate; older requests are rejected")

even = Ballots(4)
assert not even.elect(0, 1, [0, 1])[0]
assert not even.elect(2, 1, [2, 3])[0]
assert not Ballots(5).elect(0, 1, [0, 0, 0])[0]
print("2-2 split stalls; repeating one voter cannot manufacture a majority")
print("PASS: fixed-membership ballot rules only; no replicated log or network")

Expect four confirmation lines. A three-member side wins, a two-member side loses, and a second candidate cannot reuse votes already given in the same term. A later term can elect a different candidate. Older requests then fail, a two-two partition stalls, and three copies of one identity remain one vote.

The exact revised example passed with Python 3.12.14 on Linux. Those assertions establish only this ballot model’s behavior. They do not demonstrate log replication, crash persistence, membership reconfiguration, timing, or a live cluster recovering from partition.

Sources

In Search of an Understandable Consensus Algorithm (Raft), leader election and majority quorum in section 5, checked 2026-09-09.
etcd: etcd versus other key-value stores, leader election and distributed coordination over Raft, checked 2026-09-09.
ZooKeeper Internals, majority quorums for atomic broadcast and leader election, checked 2026-09-09.

Election · XB Field Notes