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.[n1]
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).
Related¶
- 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
Editorial Notes¶
Form Classification¶
Form family: Decision, Gate & Allocation
Rationale: Term/Epoch Leader Election operates as a case-specific gate, selection, routing, prioritization, or resource disposition because it 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.
Independent corroboration: The frozen evidence defines Term/Epoch Leader Election as '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', so its operative form is Decision, Gate & Allocation.
Nearest alternative: Protocol, Workflow & Routine — Term/Epoch Leader Election includes features of a repeatable ordered procedure or handoff sequence that coordinates action, but its defining operation is a case-specific gate, selection, routing, prioritization, or resource disposition.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: The defining operation is: 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. In the computer_science lineage, that operation is specifically evidenced by authoritative or primary work that defines monotonically increasing terms, at most one elected leader per term, and rejection of messages from stale terms. This makes computer_science the best historical origin, while the retained alternates document contributing methods and later applications rather than being mistaken for coequal origins.
Related originating lineages:
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: 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….
- Organizational & Management Science — organizational_management supplies a historically relevant parallel or contributing practice for the defining operation—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—but the evidence does not make it the best primary lineage.
- Systems Thinking & Cybernetics — Systems science's feedback, stock-flow, boundary, and regulation tradition provides a formative adjacent lineage for the same term epoch leader election operation.
Review resolution: The blind reviewers disagree on primary lineage (organizational_management versus computer_science), so I adjudicated the mechanism rather than inheriting either label. The defining operation is: 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. In the computer_science lineage, that operation is specifically evidenced by authoritative or primary work that defines monotonically increasing terms, at most one elected leader per term, and rejection of messages from stale terms. This makes computer_science the best historical origin, while the retained alternates document contributing methods and later applications rather than being mistaken for coequal origins. The cited Ongaro & Ousterhout, Raft consensus directly supports the mechanism-specific operation and its disciplinary lineage. I retain all independently explained historical alternates without a numeric cap. origin_mode=single_lineage records how the mechanism arose; domain_reach=specialized separately records how broadly it can now be applied.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
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.
[n1] 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. ↩