Raft: a majority must agree before any write commits
Raft keeps several copies of the data consistent. At any moment one member is the leader and accepts every write. It appends the change to its log, sends it to the followers, and once a majority (the quorum) has stored it the entry is committed and acknowledged. Reads of committed data can be served consistently.
The quorum rule explains the sizing advice. Quorum is floor(n/2)+1. Three members need two, so one can fail. Four members need three, so still only one can fail: the fourth machine costs money and adds replication overhead without improving fault tolerance. Five members tolerate two failures. Beyond five, each extra member slows commits for little gain, so three or five is the norm. The animated bars reveal this comparison.
When the leader fails or is partitioned, followers have randomised election timeouts. The first to expire becomes a candidate and asks for votes; a majority makes it the new leader. Randomisation avoids all followers becoming candidates at once and splitting the vote. While an election runs, usually under a second, etcd accepts no writes, so the API server cannot change state. Frequent elections caused by flaky networking or slow disks therefore degrade the whole cluster.
Placement matters: spread members across failure domains such as zones, but keep latency low and disks fast. etcd is sensitive to disk fsync latency, which is why control plane nodes use SSDs.