Consensus: Raft and Paxos simply explained
In short: Consensus algorithms let a group of nodes agree on a single ordered log of decisions, even if some nodes crash. Raft does this with an elected leader and majority acknowledgement; Paxos achieves the same safety with a different structure. A cluster of 2f+1 nodes survives f failures.
What consensus solves
Many systems need several nodes to agree: which node is the leader, whether a transaction committed, what the current configuration is. Consensus is the problem of getting a group to agree on one value, or one ordered sequence of values, even when some members crash or messages are delayed.
The usual approach is a replicated state machine: every node keeps the same log of commands in the same order and applies them deterministically, so all nodes reach the same state. Tools such as etcd (used by Kubernetes), Consul and ZooKeeper provide this as a service.
Raft: leader election
Raft was designed to be easier to understand than Paxos. Time is divided into numbered terms. Each node is a follower, a candidate or the leader.
- Followers expect regular heartbeats from the leader.
- If a follower hears nothing before its randomised election timeout, it increments the term, becomes a candidate and votes for itself.
- It asks other nodes for votes. Each node votes for at most one candidate per term, and only for one whose log is at least as up to date as its own.
- A candidate with votes from a majority becomes leader and starts sending heartbeats.
- Randomised timeouts make split votes rare; if one happens, a new term starts.
Raft: log replication
Clients send commands to the leader. The leader appends each command to its log and sends it to followers. Once a majority have stored it, the entry is committed and can be applied and answered. Because any two majorities overlap in at least one node, a new leader is always elected from nodes that hold every committed entry, so committed data is never lost.
| Cluster size | Majority needed | Failures tolerated |
|---|---|---|
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 7 | 4 | 3 |
An even number adds cost without adding tolerance, which is why clusters are usually 3 or 5 nodes. Larger clusters also slow down writes because more nodes must respond.
Paxos and limits
Paxos, described by Leslie Lamport, came first. Proposers suggest values with increasing proposal numbers; acceptors promise to ignore older proposals and accept a value once a majority agree. Multi-Paxos repeats this for a log and, in practice, also uses a stable leader. Raft and Multi-Paxos offer similar guarantees; Raft simply packages them more clearly.
Both assume nodes may crash but do not lie. Tolerating malicious nodes needs Byzantine fault tolerant protocols, which need at least 3f+1 nodes; these appear in some blockchain consensus designs.
Tip: never stretch a 3-node etcd cluster across two sites with two nodes on one side. If that side fails, the survivor has no majority and the cluster stops accepting writes.
At work, check cluster health before maintenance and replace one member at a time:
etcdctl endpoint status --cluster -w table
etcdctl endpoint health --clusterPractice
How many node failures can a 5-node Raft cluster survive?
Why do Raft nodes use randomised election timeouts?
When is a Raft log entry committed?
Key takeaways
- Consensus lets nodes agree on one ordered log despite crashes.
- Raft uses terms, leader election and majority acknowledgement.
- A cluster of 2f+1 nodes tolerates f failures; use odd sizes.
- Paxos gives similar safety with a different structure.
- Malicious nodes need Byzantine fault tolerant protocols.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.