Distributed Systems for Backend Engineers · Data Distribution and Agreement
Consensus: Raft and Paxos Intuition
How nodes agree on a value or a log despite failures.
Consensus lets a group of nodes agree on a sequence of values (a replicated log) despite crashes, as long as a majority is alive and connected. Raft (etcd, Consul, CockroachDB, Kafka KRaft) elects a leader with terms and votes; the leader appends entries and commits them once a majority acknowledges. Paxos is the classic equivalent. You rarely implement consensus — you use systems built on it for leader election, configuration, locks and strongly consistent metadata.
Quorum sizes
| Cluster size | Tolerates failures | Majority needed |
|---|---|---|
| 3 nodes | 1 | 2 |
| 5 nodes | 2 | 3 |
| 7 nodes | 3 | 4 |
| 4 nodes | 1 (no better than 3) | 3 |
Raft in one paragraph
Followers time out → become candidate (term+1) → request votes → majority → leader
Client writes go to the leader → appended to its log → replicated to followers
Entry committed when stored on a majority → applied to state machines in log order
Partitioned minority can't elect a leader or commit → no split brain
Common pitfalls
- Even-sized clusters (no extra fault tolerance).
- Spreading 3 consensus nodes across 2 zones.
- Building your own consensus instead of using etcd/ZooKeeper/managed services.
Key points
- Majority quorum agreement
- Raft = leader + replicated log
- Use, don't build, consensus
Further reading: The Raft Consensus Algorithm
Practice questions
Why are consensus clusters usually 3 or 5 nodes?
Answer
Odd sizes maximize fault tolerance per node: 3 tolerates 1 failure, 5 tolerates 2; adding a 4th node doesn't increase tolerance.
How does Raft prevent split brain during a partition?
Answer
Only the side with a majority can elect a leader and commit entries; the minority side can't make progress.
Open in the app to mark lessons complete, take notes and track your progress.