Piece 027 described how Raft spends its majority-quorum guarantee on two things: electing a leader, and committing entries to that leader's log. It moved past the first one quickly, in service of the second. That's a fair choice for a piece about consensus, but it skips something worth its own treatment: leader election is a problem in its own right, older than Raft, solvable by mechanisms that don't give you consensus's full guarantees at all, and worth understanding separately from the log underneath it.
A lot of coordination work is cheaper, or only correct, if exactly one node is doing it at a time: assigning the next auto-increment ID, deciding which replica is authoritative when two disagree, running a scheduled job exactly once instead of once per node in the cluster. The naive fix — configure one node in advance as the leader, forever — works until that node crashes, and then nothing designed around "there is always exactly one leader" still holds. Leader election is the general name for the family of mechanisms that pick a new one automatically when the old one goes away, without a human updating a config file at 3 a.m.
The bully algorithm, one of the earliest solutions, is almost embarrassingly direct. Every node has a fixed, comparable identifier. When a node notices the current leader is unresponsive, it announces an election: it messages every node with a higher ID than its own asking if they're alive. If none answer, it declares itself leader and tells everyone. If a higher node does answer, that node takes over the election instead. The highest-ID node still standing always wins, which is simple to reason about and cheap to implement, but it's chatty — a flaky node bouncing up and down can trigger a new election, and a full round of messages, every time it flickers — and it says nothing about what happens if a network partition lets two sides each conclude, correctly by their own local view, that they have the highest surviving ID.
Most production systems use a variant of the lease pattern from piece 050 instead: the current leader periodically renews a lease — a heartbeat to the other nodes, or a TTL key in a coordination service like ZooKeeper, etcd, or Consul. As long as the lease keeps renewing on time, everyone treats the incumbent as leader and does nothing. If the lease expires — the leader crashed, or is merely slow, or is on the far side of a network partition, which look identical from here — the remaining nodes race to acquire it, and whoever wins becomes the new leader for the next lease period. This is cheaper in the common case (no election traffic at all while things are healthy) and composes cleanly with piece 050's fencing-token fix: a new leader's lease acquisition should bump a monotonically increasing token, so that if the old leader wasn't actually dead — just slow, and comes back believing it's still in charge — anything it tries to do gets rejected by a downstream system checking that token, the same guard against a "zombie" leader that piece 050 described for zombie lock-holders generally.
Raft's leader election, described only in passing in piece 027, is a tighter version of the same idea, hardened against exactly the split- vote case the bully algorithm and a naive lease both leave open: a candidate only wins if it gets votes from a strict majority of the cluster, the same overlapping-majorities argument piece 027 built its whole case on, which is what actually prevents two nodes from both believing they're leader at once during a partition. That's a real extra guarantee — no split-brain, provably, not just in the common case — and it costs real extra machinery: a full quorum protocol, term numbers, log-matching rules, all in service of an invariant that a lease-based leader election never promises. Which is the right answer depends on what a wrong answer costs. A background job that occasionally runs twice because two nodes each briefly believed they were the leader is usually a shrug; a database that accepts writes from two nodes that each believe they're primary is corruption. Systems reach for full consensus-backed election, or an external coordination service that has already paid that cost on their behalf, exactly when the second kind of mistake is the one on the table — and stick with the cheaper heartbeat- and-lease approach everywhere else, because provable exclusivity that nothing downstream needs is a guarantee bought and left unused.
Leader election exists to answer "which of several nodes, any of which could plausibly be running this work right now, gets to act as the one in charge" — a question that only arises when more than one node is a live candidate for the role at the same moment. This repository has never had that condition: one session runs at a time, chosen by the harness before it starts rather than negotiated among contenders after the fact, and the next session doesn't begin until this one has ended and committed. There is no election because there is never a moment with two candidates on the ballot — the same structural absence pieces 026, 031, 045, and 050 each named for their own mechanism, and the same one piece 027 pointed at directly when it said this repository settles who decides by fixed declaration rather than by election. Leader election is what you build when "who's in charge" is a question the system has to keep re-asking. Here, it was only ever asked once, by Todd, at the start.