Several machines need to agree on an ordered sequence of operations. Some will fail. The network will drop and delay messages. Two of them must never both believe they are in charge.
Consensus algorithms solve this, and Raft is the one most modern systems use because it was designed to be understandable — which matters, because the operational behaviour of a great many distributed databases follows directly from it.
What changed in 2026
- It remained the default choice. Raft continued to underpin most new distributed data systems.
- Election tuning got attention. Balancing fast failure detection against spurious elections became a recognised operational concern.
- Multi-region deployments exposed the latency cost. Cross-region consensus proved expensive enough to shape topology decisions.
- Witness and learner nodes spread. Non-voting members that help with placement without affecting quorum arithmetic became common.
The two mechanisms
Leader election. Nodes start as followers. If a follower hears nothing from a leader for a timeout, it becomes a candidate and requests votes. A candidate receiving votes from a majority becomes leader. Randomised timeouts prevent every node becoming a candidate simultaneously.
Log replication. All writes go to the leader, which appends to its log and sends the entry to followers. Once a majority have written it, the entry is committed and applied. The leader tells followers, which apply it too.
Everything operationally interesting follows from those two.
Why writes do not scale with cluster size
All writes go through the leader. Adding nodes adds replicas, not write capacity — and each additional node is another follower the leader must send entries to.
So a larger cluster does not write faster. It tolerates more failures and can serve more reads if the system allows follower reads.
| Nodes |
Majority |
Failures tolerated |
| 3 |
2 |
1 |
| 4 |
3 |
1 |
| 5 |
3 |
2 |
| 6 |
4 |
2 |
| 7 |
4 |
3 |
Notice that even numbers gain nothing. Four nodes need three for a majority and tolerate one failure — identical to three nodes, with an extra machine to run and an extra follower to replicate to. Odd sizes only.
Why a minority cannot proceed
The majority requirement is what prevents split brain. If a network partition separates two nodes from three, only the side with three can elect a leader and commit writes. The minority side has a leader that cannot get majority acknowledgement, so it accepts nothing.
That is correct and it means a minority partition is unavailable for writes. Clients on that side see failures until the partition heals. This is the consistency-over-availability choice, per CAP theorem explained, and it is not configurable — it is what consensus means.
Elections cost availability
When a leader fails, followers wait out their election timeout, then elect a new leader. During that window there is no leader and no writes are accepted.
The timeout is a genuine tradeoff. Short timeouts detect failure quickly and cause spurious elections when the network is briefly slow — and a spurious election is itself a brief outage. Long timeouts avoid that and extend the unavailable window after a real failure.
The practical consequence: a Raft-based system has brief write unavailability whenever the leader changes, whether from failure, a rolling restart, or a network blip. Planning around that means retry logic in clients rather than assuming continuous availability.
Cross-region deployments make this worse. Every write waits for majority acknowledgement, so if the majority spans regions, every write pays a cross-region round trip. This frequently pushes teams toward keeping a voting majority within one region and using non-voting replicas elsewhere.
Common mistakes
- Even-numbered clusters. Extra cost, no extra fault tolerance.
- Expecting writes to scale with nodes. They do not; all writes go through the leader.
- Election timeouts too short. Spurious elections under normal network variance.
- A voting majority spanning high-latency links. Every write pays the round trip.
- No client retry logic. Elections produce brief write failures.
- Assuming a minority partition stays available. It cannot, by design.
- Two-node clusters. A majority of two is two; one failure stops everything.
FAQ
Can I read from followers?
Depends on the system. Follower reads may return slightly stale data unless the implementation provides a mechanism to ensure currency. Where offered it is a useful way to scale reads.
How long is an election?
Typically a small number of seconds, governed by the timeout configuration. It is brief and not instantaneous, and clients must tolerate it.
Is Raft the same as Paxos?
They solve the same problem. Raft was designed for understandability, with explicit leader election and log replication, which is why it dominates newer implementations.
What are witness nodes?
Members that participate in voting without storing full data, used to establish a majority in a third location cheaply. Useful for two-region deployments needing a tiebreaker.
Where to go next
For the consistency model consensus provides, read CAP theorem explained. For the leaderless alternative, quorum reads, and for the replication mechanics, synchronous replication.