A 911 dispatch platform sizes etcd for HA. Why do operators typically choose an odd etcd member count?
Select an answer to reveal the explanation.
Short Explanation
Consensus is a majority vote—three or five judges beat a hung jury of four. Odd etcd member counts make “more than half” clean when someone drops offline. Even counts aren’t illegal, but they waste a seat without buying better failure tolerance.
Full Explanation
Operators sizing etcd for a 911 dispatch HA platform typically choose an odd member count because majority quorum is easier to maintain with odd counts such as 3 or 5, reducing wasted capacity that does not improve failure tolerance. Consensus is a majority vote—three or five judges beat a hung jury of four. Odd counts are not required because Kubernetes only starts on prime-numbered hosts—that is nonsense. Even counts do not make etcd faster by avoiding voting; Raft still needs majority. etcd does not ignore member count; quorum math is central, and apiserver replica count alone does not define etcd quorum. Exam caveat: Odd counts maximize tolerance for a given size; backups still required. Operational check: Deploy 3 or 5 members across failure domains, verify member list, and document how many losses the municipal design can survive. In municipal platform operations, record the rationale in the change ticket so future on-call staff know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same control still holds under the cluster’s current minor version and addon revisions used by the civic platform team.