Consensus Explained: Raft, Paxos & Majority Quorums

🟠 Fundamentals · Senior → 🔴 super-senior deep dive

Here's a deceptively hard question: if you have five servers that must all agree on a single value — say, "who is the leader?" or "what's the next entry in the log?" — how do they agree when messages get delayed, servers crash, and nobody has a global clock? That's the consensus problem, and it sits at the heart of every reliable distributed system. Raft and Paxos are the two famous algorithms that solve it. This is senior/staff territory, so we'll go from the intuition all the way down. Let's make it click.

Why is agreeing so hard?

In one process, agreement is trivial — you just have the value. Across a network it's brutal because: messages arrive late or out of order, a server can crash at the worst moment, and you can't tell "crashed" apart from "just slow." If two servers both think they're in charge (split-brain) and each accepts different writes, your data forks — a nightmare. Consensus algorithms exist to make that impossible.

The magic ingredient: majority quorum

🟠 The core trick behind both Raft and Paxos is the majority (quorum). A decision is official only when more than half the nodes accept it. Why does that work? Because any two majorities of the same cluster must share at least one node — and that overlapping node remembers the previous decision and refuses to contradict it.

This overlap is the whole safety guarantee. It's also why clusters are sized odd (3, 5, 7): a 5-node cluster tolerates 2 failures (3 still form a majority), and odd sizes avoid wasteful ties.

Raft: consensus you can actually understand

🔴 Paxos (Leslie Lamport, 1990s) came first and is famously hard to follow. Raft (2014) was designed to do the same job but be understandable — and it won: etcd, Consul, and CockroachDB all use it. Raft breaks consensus into three digestible pieces:

• Leader election: one node is the leader; everyone else is a follower. All writes go through the leader. Time is divided into numbered terms; if followers stop hearing the leader's heartbeat, one becomes a candidate, requests votes, and whoever wins a majority becomes the new leader for a new term.
• Log replication: the leader appends each command to its log and ships it to followers. Once a majority have stored an entry, it's committed and applied — this is the consensus step in action.
• Safety: rules (like "only a node with an up-to-date log can win an election") guarantee committed entries are never lost or reordered, even across leader changes.

The mental model: Raft keeps a replicated log identical on every node, and because they replay the same log, they behave as one reliable machine — a replicated state machine. That's how a group of fragile servers becomes a single, crash-tolerant source of truth.

Leader-based, and why that's fine

🔴 A common worry: "isn't the leader a single point of failure?" No — because leader election is itself done by consensus. If the leader dies, the remaining majority elects a new one within a heartbeat timeout (often 150–300 ms). Writes pause briefly, then resume. You trade a moment of unavailability during failover for strong consistency the rest of the time — a very deliberate CAP choice toward CP.

Where you actually meet consensus

Notice the pattern: you rarely implement Raft yourself — you use a system that already did. The senior skill is knowing when your design needs it: any time you need one agreed answer (a single leader, a lock, a config value) that survives crashes, reach for a consensus-backed store like etcd or ZooKeeper rather than rolling your own.

The interview-ready summary

"Consensus is getting unreliable nodes to agree on one value and never disagree. Both Paxos and Raft solve it using a majority quorum — since any two majorities overlap, decisions can't contradict. Raft makes it understandable via leader election + replicated log: writes go through an elected leader, and an entry commits once a majority store it. I'd run an odd-sized cluster (5 nodes tolerate 2 failures) and, in practice, lean on etcd or ZooKeeper rather than implement it myself." That answer shows you understand the mechanism, the safety argument, and the pragmatic reality.

What to read next

• Database Replication — where the replicated log idea lives day to day
• Consistency Models — the strong consistency consensus buys you
• The CAP Theorem — why consensus systems pick CP
• ← The complete System Design guide (hub)

← Capacity estimation · LSM-tree vs B-tree →