Term/Epoch Leader Election¶

Leader-election protocol — instantiates Assumption-Bounded Distributed Agreement

Chooses at most one leader per monotonically increasing term, so a stale leader from an older term can always be recognized and out-ranked — turning 'who is in charge?' into a question with a single, ordered answer.

Most agreement protocols need a single participant to coordinate — but choosing that participant, in a network that cannot tell a dead leader from a slow one, is its own agreement problem. Term/Epoch Leader Election solves it with the monotonic term. Time is divided into numbered terms (also called epochs, views, or ballot generations), each stamped on every message; a term has at most one leader, elected by a majority of votes in which each participant grants only one vote per term. That one-vote rule is what forbids two leaders in the same term, and the ever-increasing number is what makes staleness self-evident: any message from an older term is instantly recognized and rejected, and any leader that sees a higher term steps down. The winner holds a bounded mandate — it is the decision-authority for its term and no longer. The mechanism's whole job is to make "who may propose right now?" a question with one ordered, unambiguous answer.

Example¶

A replicated relational database runs one primary and four hot standbys behind automatic failover. The primary's host loses power. The failure detector's suspicion of it crosses the action threshold, and a standby that has stopped hearing heartbeats increments the term from 7 to 8 and requests votes, advertising how current its own copy of the data is. Standbys that have not yet voted in term 8 — and that judge the candidate at least as up-to-date as themselves — grant their vote; on collecting a majority, the candidate becomes primary for term 8 and begins accepting writes. Moments later the old primary's host reboots and it tries to accept a write under term 7. The first peer it contacts is already in term 8 and rejects the message as stale; the old primary learns it has been superseded and demotes itself to standby. At no point were there two primaries accepting writes in the same term, so no split-brain divergence could occur.^[1]

How it works¶

Number the terms, stamp every message. A strictly increasing term is the logical clock of leadership; comparing terms is how any participant ranks a claim as current or stale.
One vote per participant per term. Because no participant will vote twice in the same term, two candidates cannot both assemble a majority in one term — the anti-split-brain core.
Only the sufficiently-current may win. A candidate must be at least as up-to-date as its voters (by log/commit position), so an election can never hand leadership to a node missing committed data.
Randomize to break ties, higher term always wins. Randomized election delays keep candidates from perpetually splitting the vote, and any higher term seen in the wild forces an older leader to stand down.

Tuning parameters¶

Election timeout and its randomization — how long silence is tolerated before a candidacy opens, and the jitter that de-synchronizes rivals. Shorter timeouts fail over faster but risk needless elections; randomization suppresses split votes.
Up-to-date eligibility test — how strict the "at least as current as its voters" check is. Stricter tests refuse to elect a lagging node (protecting committed data) but can leave no eligible candidate available.
Leadership lease / renewal interval — how long a won mandate is honored without a fresh heartbeat. Longer leases cut churn but slow the reaction when a leader really dies.
Pre-vote step — an optional round that checks a candidate could win before it bumps the term, so a partitioned node cannot inflate the term and disrupt the cluster when it rejoins.

When it helps, and when it misleads¶

Its strength is that it collapses "who is in charge?" to a single, ordered, cheaply-checkable answer: the monotonic term makes stale leadership self-announcing, and a stable elected leader is exactly what most agreement and replication protocols need to make progress at all.

Its danger is mistaking it for more than a liveness mechanism. Electing a leader provides someone to coordinate; it does not, by itself, preserve what the previous leader had in flight — that safety job belongs to the up-to-date restriction and to view-change. Aggressive timeouts cause election churn, a cluster that flaps leadership under load; a partitioned node can inflate the term and disrupt on return unless pre-vote guards against it; and the whole thing rides on a failure detector whose suspicion can simply be wrong. The classic misuse is treating a won election as license to overwrite state — letting a fresh leader that is missing committed entries erase them. The discipline is to gate eligibility on being at least as current as any committed decision, to add pre-vote, and to remember that suspicion is not death.

How it implements the components¶

round_epoch_and_leadership_state — it owns the monotonic term/epoch counter and the identity of the current leader; this is the ordered "generation" every other message is stamped against.
decision_authority_boundary — it confers and bounds the leader's mandate: who may propose, and only until the term ends or a higher term supersedes it, so authority is always scoped and revocable.

It does not carry the previous leader's committed and in-flight decisions safely across the handoff (safety_liveness_contract, commitment_boundary → View-Change Protocol), replicate the log the leader then writes (state_consistency_guard → Raft-Style Replicated-Log Protocol), or produce the suspicion signal that triggers an election (failure_detector → Heartbeat and Suspicion Detector).

Instantiates: Assumption-Bounded Distributed Agreement — it supplies the single, ordered leadership that liveness-driven agreement depends on.
Consumes: Heartbeat and Suspicion Detector supplies the suspicion signal that opens an election; Write-Ahead Vote Log durably records each participant's term and vote so a reboot cannot cause a second vote in the same term.
Sibling mechanisms: View-Change Protocol · Heartbeat and Suspicion Detector · Quorum or Consensus Commit · Timeout Policy · Byzantine Fault-Tolerant Quorum Protocol · Consensus Fault-Injection Test · Joint-Consensus Membership Change · Paxos-Style Quorum Protocol · Raft-Style Replicated-Log Protocol · Randomized Common-Coin Protocol · Signed Quorum Certificate · Write-Ahead Vote Log

Notes¶

Leader election and view-change are constantly confused because in some protocols they are fused. The clean division is: election decides who leads next; View-Change Protocol guarantees what — the decisions already committed — survives the switch. Election alone gives liveness; without the up-to-date restriction and a safe handoff, a new leader can be perfectly legitimate and still erase history.

References¶

[1] The "at most one leader per term (epoch)" invariant, enforced by one-vote-per-term majority election and a monotonic term number, is the leadership core of protocols such as Raft (terms) and ZooKeeper's ZAB (epochs). Pairing it with an up-to-date restriction on eligible candidates is what prevents an election from losing committed data. ↩