Consensus & Leader Election

9.Agreeing on One Answer, Together

M

In this chapter

We'll meet consensus and leader election as the real, general mechanism for getting distributed machines to safely agree on one true leader — majority-of-all-nodes voting, the real safety rule both Raft and Paxos implement, and exactly what would have prevented only one side of a partition from ever claiming authority.

10–12 min

The Problem in Real Life

Sarah has the real topology question answered — leader/follower or leaderless, either is a real, workable choice. What she doesn't have yet is the actual mechanism for choosing a leader, in a leader/follower system, when machines can fail or become unreachable at any real moment.

"Just pick one" isn't a real answer once more than one machine might independently, honestly believe it should be the one picked.

M

Who actually gets to decide who's the leader, if the machines themselves can't fully trust each other?

Mike

Assuming Agreement vs. Actually Proving It

Consensus is the real, general problem

Getting distributed machines to agree on one true answer, even when some can't currently be reached.

Leader election requires a genuine majority

More than half of ALL nodes, not just reachable ones — the real safety rule that limits authority to one side at a time.

Raft and Paxos both implement this shape

Nodes propose, a genuine majority agrees, only majority-backed decisions are ever treated as final.

This directly would have fixed the incident

A majority-of-three requirement means only the 2-region side could safely elect a leader; the isolated region correctly couldn't.

Consensus & Leader Election

Consensus is the real, general problem underneath this question: getting a distributed set of machines to agree on one single, true answer — who's the leader, what the correct value is — even when some of them can't currently be reached, and even when machines can't simply trust each other's own claims at face value.

Leader election is consensus applied to one specific, extremely common question: deciding which single node gets to act as leader right now. It's the real mechanism a leader/follower system (from two chapters back) actually needs to be a genuine, disciplined system, not just an accident of whichever region happened to write first.

  • The real, load-bearing rule: a leader election only succeeds with a genuine majority of all nodes in the system — not just a majority of the nodes currently reachable. This single rule is what makes leader election a real answer to split-brain: during a partition, at most one side can ever hold a true majority of the total node count, so at most one side can ever successfully elect a leader.
  • Raft and Paxos are the two real, well-known algorithms that implement exactly this shape — genuinely agreeing on a single leader (or a single value) across unreliable, partially-unreachable machines, using majority votes as their real safety mechanism. Raft, specifically, adds a real, practical idea worth naming: a randomized election timeout, so if a node hasn't heard from a leader in a while, it waits a random, staggered amount of time before proposing itself — reducing the real chance of two nodes proposing at exactly the same moment and splitting the vote.

A Real Leader Election, Step by Step

No leader currently, or the old one is unreachable

A real, common trigger — the old leader's region went dark

a node proposes itself

"I'll be leader — vote for me"

Sent to every other reachable node

every reachable node votes, once

Votes counted

Each node votes for at most one candidate per election round

only if a genuine majority agrees

Leader confirmed

More than half of ALL nodes (not just reachable ones) voted yes

This course won't walk through either algorithm's full internal implementation — that's genuinely a deeper, more specialized topic than this Act needs. The real shape that matters, and the shape both algorithms share: nodes propose, a genuine majority has to agree, and only a majority-backed decision is ever treated as final and authoritative. Applied to GreenMart's own incident directly: if leader election for the scarce gift-box inventory had required a genuine majority of all three regions, the side of the partition holding two regions (a real majority) could have safely elected a leader and kept selling with real authority; the single isolated region — genuinely unable to reach a majority — would have correctly refused to act as an authoritative leader, and the oversell simply couldn't have happened the way it did.

Key Takeaway

Consensus is the real, general problem of getting distributed, partially-unreachable machines to agree on one true answer — leader election is that problem applied to choosing who's in charge right now. The real safety mechanism, implemented by both Raft and Paxos, is requiring a genuine majority of all nodes (not just reachable ones) before any decision counts as final — which is precisely why only one side of any partition can ever legitimately claim authority at once.

Why This Matters

This is the real, concrete mechanism that would have prevented GreenMart's own incident from the start — not a general principle, a specific, checkable rule (majority of all nodes, not just reachable ones) that the next chapter names directly against the incident itself.

GreenMart now has the actual, general mechanism for choosing a real leader safely across unreliable machines — majority-quorum consensus, the real idea behind Raft and Paxos. What actually happened when GreenMart's own system didn't have this discipline in place is exactly where the next chapter goes.

Next