Why does adding a controller to make the quorum an even number (e.g. going from 3 to 4) add no extra fault tolerance?
answer
- F = N − majority; jumps only on odd steps
- 3→4: tolerance stays 1, just more to break
- even count → possible 2-2 tie → stall
- tie = unavailable, never two leaders
- 3/5/7 like ZooKeeper/etcd
basics
~20 sFault tolerance depends on the majority, and the majority jumps the same way. 3 voters need 2 and tolerate 1; 4 voters need 3 and still tolerate only 1 — but with one more node that can fail.
solid answer
~40 sFault tolerance is N minus the majority. For 3 voters: majority 2, tolerates 1. For 4 voters: majority is floor(4/2)+1 = 3, so it tolerates only 4−3 = 1 — the same as 3 voters. You added a node that costs more write coordination and gives one more thing that can break, without raising the number of failures you survive. Worse, an even count makes ties more likely in failure scenarios: split 2-2, neither side has a majority, so nobody can lead. Odd counts maximize tolerance per node and avoid symmetric ties. That is why Kafka (like ZooKeeper and etcd) recommends 3, 5, or 7 voters and never 4 or 6.
go deeper
Just remember: even numbers add no extra safety, so always use odd (3 or 5).
Show the F = N − majority math for 3/4/5 and explain the 2-2 tie stall.
Connect to the latency cost of a larger majority and to the consistency-over-availability design choice.
Frame parity as a general quorum-system property shared with ZK/etcd, and discuss transient even states during reconfiguration.
## The core formula A Raft/quorum system commits only with a **strict majority** of voters. For N voters: - majority M = floor(N/2) + 1 - failures tolerated F = N − M = floor((N−1)/2) ## Walking 3 → 4 → 5 | N | majority M | tolerated F = N−M | |---|-----------|-------------------| | 3 | 2 | 1 | | 4 | 3 | 1 | | 5 | 3 | 2 | Going 3 → 4: F stays at **1**. You added a whole node, but the majority requirement also went up by one (2 → 3), so the extra node is fully 'consumed' by the higher bar. Net availability benefit: zero. Going 4 → 5: now F jumps to 2 — the second added node finally buys a failure. So failures-tolerated only increases on the **odd** steps. Even sizes are strictly dominated: they have the same tolerance as the odd size below them but with an extra node that: 1. **Can itself fail or partition** — more moving parts, more maintenance, more chance any single node is down during a planned restart. 2. **Costs more coordination** — every committed metadata write must be acknowledged by a majority; a larger majority (3 vs 2) means more round trips and higher tail latency. ## The tie problem (split votes) Even counts are not just wasteful — they are slightly worse for liveness. With 4 voters, a network partition can produce a clean **2-2 split**. Neither side has the majority of 3, so neither side can elect a leader, and the quorum stalls until the partition heals. With 3 voters, a partition produces 2-1: the 2-side still has a majority and keeps operating. Odd sizing makes a symmetric, no-majority split impossible. Importantly, the tie problem does NOT mean both sides become active (that would be split-brain). Raft's majority requirement guarantees at most one side can win, so a tie causes **unavailability**, never two active controllers. This is the deliberate trade: KRaft chooses consistency (one leader or none) over availability. ## Why everyone recommends odd Kafka KRaft, ZooKeeper ensembles, etcd, and Consul all recommend 3/5/7. The reasoning is identical: per added node, you only gain fault tolerance on odd transitions, and even counts invite ties. So you should always run an odd quorum. ## Edge case: degraded operation If a 5-voter quorum loses 2 voters, it runs on 3 — and is now in a state with **no remaining tolerance** (a 3rd loss is fatal). Sizing is about steady state; operators should restore failed voters promptly to regain headroom.
- Does a 2-2 tie cause split-brain (two active controllers)?No. Neither side reaches the majority of 3, so neither can elect a leader — the result is unavailability, not two leaders. Raft's majority rule guarantees at most one active controller.
- If even counts are bad, why might you briefly run 4 voters?Only transiently during a dynamic quorum reconfiguration (adding/removing a voter) — you pass through an even size momentarily but should not run there steady-state.
saying these in an interview costs you the question
- Claiming 4 voters tolerate 2 failures (they tolerate 1, same as 3).
- Claiming an even split causes split-brain with two active controllers (it causes a stall).
- Saying more voters always means more safety regardless of parity.
- Believing the extra even node improves write throughput (it increases the majority and latency).