What it is
Consensus is how a group of machines agrees on a single value (or a single ordered log of values) even when some machines crash and messages are delayed. It is the foundation under lock services, metadata stores, and databases that promise zero data loss. Raft is the consensus algorithm to know: it keeps a replicated log, elects one leader to order every write, and commits an entry once a majority has stored it.
Important
Key takeaway: Consensus buys agreement that survives failures at a price: every write waits for a majority, so throughput is limited to one leader and latency includes a round trip to the second-closest replica. Use it for the small, critical core (who is leader, who holds the lock, the commit decision), and keep bulk data on cheaper replication.
When you care
“How do replicas agree on who the leader is?” and “why three or five nodes, not four?” come up whenever a design needs a strongly consistent core: locks, configuration, coordinators, or a CP database.
Note
Interview signal: You do not need to derive Raft. Saying “a replicated log with a leader, commit on majority, and a new election when the leader goes quiet” and giving the quorum arithmetic is the expected depth. Knowing it is CP (a minority partition refuses to write) is the senior addition.
The guarantees and the arithmetic
A cluster of n = 2f + 1 nodes tolerates f failures, because a majority (f + 1) is still alive and any two majorities overlap in at least one node.
| Nodes | Majority needed | Failures tolerated |
|---|---|---|
| 3 | 2 | 1 |
| 4 | 3 | 1 (no better than 3) |
| 5 | 3 | 2 |
| 7 | 4 | 3 |
That is why clusters use odd sizes: a fourth node adds cost and a larger quorum without tolerating another failure. Larger clusters tolerate more failures but make every write wait on more acknowledgments, so three or five is typical.
How Raft works
A write commits when a majority, counting the leader, has it.
Roles and terms. Each node is a follower, candidate, or leader. Time is divided into numbered terms; each term has at most one leader.
Leader election.
- The leader sends periodic heartbeats. A follower that hears nothing for a randomized election timeout (a typical range is 150 to 300 ms) becomes a candidate, increments the term, and asks the others for votes.
- A node grants one vote per term, and only to a candidate whose log is at least as up to date as its own. This rule guarantees that any elected leader already holds every committed entry.
- A candidate with votes from a majority becomes leader. The randomized timeout makes split votes rare and quickly resolved.
Log replication.
- All writes go to the leader, which appends the entry to its log and sends it to the followers.
- When a majority (counting the leader) has stored the entry, it is committed: the leader applies it to its state machine and replies to the client.
- Followers learn the commit index on later messages and apply the entry too. Every node applies the same entries in the same order, so every state machine ends up identical.
Worked example. In a five-node cluster, a write needs the leader plus two followers: three of five. The leader’s latency is the round trip to its second-fastest follower, so one slow or dead node does not slow commits. If the leader dies, the followers’ election timeouts expire (within a few hundred milliseconds), one wins a majority vote, and writes resume. A minority partition (say two nodes) cannot elect a leader and refuses writes, which is the CP behavior.
Reads. A naive read from a follower can be stale. To read linearizably, a read goes through the leader, which confirms it is still the leader (with a heartbeat round or a leader lease) before answering. Following reads from a replica are fast but may lag.
Leader election as a building block
Services use a consensus store (ZooKeeper, etcd, Consul) to elect their own leaders: candidates race to create an ephemeral record or acquire a lock, the winner is leader, and its epoch (a fencing token) accompanies every action so a deposed leader is rejected downstream. The consensus cluster stays small and critical; the services it coordinates can be large.
Consensus per shard
Databases that need both scale and zero data loss run one consensus group per shard (range): each range has its own leader and a few replicas, so writes to different ranges proceed in parallel. A transaction that spans ranges layers a commit protocol on top. The price is consensus latency on every write.
Warning
Production reality: Consensus clusters are sensitive to timing. A leader stalled by a long garbage-collection pause or a slow disk looks dead, triggering an election; overloaded networks cause election storms. Tune timeouts to the environment, keep the cluster small and on fast disks, and run it separately from noisy workloads.
Raft, Paxos, and ZAB
All three solve the same problem. Paxos is the original, famously hard to implement and explain; Raft was designed for understandability with the same guarantees and is the common choice (etcd, Consul, many databases); ZAB powers ZooKeeper with a similar leader-based design. In an interview, “Raft-style” is enough.
When to pick what
| Need | Choose | Why |
|---|---|---|
| Agreement on a small critical value (leader, lock, config) | A consensus store (etcd, ZooKeeper) | Linearizable, survives f failures |
| Zero data loss and automatic failover for a database | Consensus per shard | A replicated log with an elected leader |
| Availability over consistency, conflicts tolerated | Leaderless quorums (not consensus) | No leader to wait for |
| High write throughput on bulk data | Not consensus on every write | One leader is a throughput ceiling |
| Strong reads | Read through the leader (or a lease) | Followers can lag |
Caution
Common mistake: Putting high-volume data through a consensus cluster. Every write is ordered by one leader and waits on a majority, so it is built for the small control plane, not the data plane. Store the data elsewhere and keep only the coordination in consensus.
Related
- Walkthrough: Designing a Distributed Lock — a lock service built on a consensus core.
- Walkthrough: Designing a Distributed Database — one consensus group per range, so zero data loss scales.
- Reference: Distributed Locks and Fencing Tokens — why agreement on the leader still needs fencing downstream.