Leader Election and Term Protocol¶
Protocol — instantiates Fault-Tolerant Distributed Consensus
Selects a temporary coordinator and fences stale ones with monotonic terms, without making the leader the source of truth.
Consensus runs far more efficiently when one participant acts as coordinator, but a coordinator that outlives its authority is a hazard: a leader that was demoted while partitioned can wake up and keep issuing orders. Leader Election and Term Protocol solves both halves. It selects a temporary coordinator by having a candidate advance a monotonic term and gather a quorum of votes, and it fences stale coordinators by stamping every action with that term so any recipient can reject anything carrying an older one. Its defining discipline is that the elected leader is a convenience, not an oracle: it is trusted to sequence proposals and drive progress, but it is never the source of a safe value on its own — a new leader must first recover the highest prior evidence, and its authority evaporates the instant a higher term appears. Election buys efficiency and progress; it never buys the right to decide unilaterally.
Example¶
A stream-processing framework runs many worker nodes, and one node must be the job manager that assigns work and writes checkpoints. The current manager's host is severed from the network mid-shift. Its workers stop hearing from it, and after a randomized election timeout one worker becomes a candidate: it increments the term from 8 to 9, persists that term to disk, and requests votes, offering evidence that its own log is at least as up to date as any voter's. A majority, seeing a newer term and adequate log state, grant their votes, and the candidate becomes leader for term 9. Meanwhile the old manager, still isolated, believes it is leader for term 8 and tries to write a checkpoint. But the checkpoint store now rejects any write not stamped with the current term 9 — the old manager's term-8 write is fenced out and fails.[n1] When the partition heals, the old manager receives a message carrying term 9, recognizes it as higher, and steps down without a fight. Two managers briefly thought they led, but only one could act, because the term traveled with every effect.
How it works¶
- Detect a stall. A liveness timeout (from the failure detector) signals that the current leader may be gone; only then does anyone consider standing.
- Randomize candidacy. Candidates wait a randomized interval before starting, so they rarely all stand at once.
- Advance and persist the term. A candidate durably increments its term, then requests votes carrying evidence of its prior state.
- Vote under restriction. Voters grant at most one vote per term and only to a candidate at least as current as themselves; a quorum makes the leader.
- Fence and step down. The new term stamps every effect so stale coordinators are rejected, and any leader that sees a higher term steps down immediately.
Tuning parameters¶
- Election timeout range — how quickly a stall triggers an election and how widely candidacy is randomized. Short timeouts recover fast but cause false elections; a wide random range prevents simultaneous candidates but adds latency.
- Candidate eligibility — how strict the "at least as up to date" requirement is. Stricter eligibility prevents a lagging node from winning and losing data but can slow recovery when the freshest node is down.
- Pre-vote gate — whether a candidate checks it could win before disrupting the current term. Pre-vote suppresses needless term churn from a flapping node at the cost of an extra round.
- Backoff on failed terms — how much a repeatedly-failing candidate backs off. More backoff calms election storms; too much extends leaderless downtime.
When it helps, and when it misleads¶
Its strength is a fast, efficient steady-state path — one coordinator sequencing proposals — plus explicit fencing that makes stale leadership harmless. It cleanly separates the question "who coordinates" from the question "what is safe."
Its limitation is that election gives no safety by itself: a leader is only useful atop underlying vote-and-quorum rules, and without fencing carried to every external resource, a stale leader can still cause damage. The classic misuse is treating the elected leader as unconditionally authoritative — letting it serve reads or issue effects without confirming its term is still current — or relying on process identity instead of the term token. The guarding discipline is to make every consequential effect carry and check the term, and to remember that the election chooses a driver, not a truth.
How it implements the components¶
leader_or_coordinator_epoch— it allocates the monotonic term that orders coordinator attempts and fences stale leaders through storage and external effects.timeout_retry_and_backoff_policy— it uses randomized election timeouts and backoff to trigger and space out candidacies without storms.protocol_phase_and_message_state— it drives the request-vote / grant-vote phase machine with one-vote-per-term and step-down transitions.
It does not implement quorum_and_intersection_policy or the durable_decision_evidence_log for the decision itself — an elected leader still needs Crash-Fault Quorum Protocol to commit a safe value; this protocol chooses the coordinator, not the value.
Related¶
- Instantiates: Fault-Tolerant Distributed Consensus — the liveness coordination mechanism.
- Consumes: Failure Detector and Heartbeat Service supplies the stall signal that triggers an election.
- Sibling mechanisms: Crash-Fault Quorum Protocol · Failure Detector and Heartbeat Service · Replicated Log Consensus Engine · Joint Consensus Reconfiguration
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: The executable protocol selects a current coordinator and fences stale leaders with monotonic terms during operation.
Nearest alternative: Protocol, Workflow & Routine — Election has ordered messages, but live authority-state control is the operative form.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Distributed-consensus research developed elected coordinators fenced by monotonically increasing terms or epochs.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
[n1] A fencing token (a monotonically increasing number attached to leadership, discussed at length by Martin Kleppmann) lets a downstream resource reject any request carrying an older token than one it has already seen, which is how a stale leader's late writes are safely rejected. ↩