Scaling data / Advanced / 8 min
Leader election and Raft consensus
Crash the leader and watch a new one win by majority vote. Writes commit only when most servers have them.
Start the simulation → Change the load, break a part, watch what happens. Free, no sign-up.
In short
- What it is
- Raft keeps one ordered log on several servers: one elected leader takes writes, copies them out, and commits each once a majority has it.
- Why it matters
- Systems like etcd, Consul and Kafka KRaft need every server to agree on the same order of changes even while some are down.
- The trade-off
- Every write waits for a majority round trip, and with fewer than half + 1 servers up nothing can be written at all.
- Say it in an interview
- "Run 2N + 1 nodes to survive N failures; the leader replicates each entry and commits it when a majority acknowledges."
Check yourself
A 5-server Raft cluster loses 3 servers. What happens?
Answer: It can no longer commit: 2 is not a majority of 5. A write commits only when a majority (3 of 5) stores it, and electing a leader also needs 3 votes.
Why does Raft randomise election timeouts?
Answer: So two followers rarely stand at the same moment and split the vote. If everyone stood at once, votes would split and no one would win; random timeouts break the tie.
How many servers does a cluster need to survive 2 failures?
Answer: 5. With 2N + 1 servers you survive N failures: 5 servers keep a majority of 3 after losing 2.