Consensus requires a majority (3 out of 5). Only partition [3,4,5] can form a quorum. If [1,2] had the old leader, it will step down. A new leader will be elected in [3,4,5].

A write is committed once replicated to a majority (including the leader). The leader can respond 'success' at that point. Slow followers catch up later.

Agreement ensures all replicas see the same transaction log in the same order. No duplicates, no missed transactions. This is the safety property.

If all nodes had the same timeout, multiple nodes might become candidates simultaneously, splitting the vote and requiring repeated elections. Randomization ensures one usually wins first.

Ephemeral nodes are tied to client sessions. When the session ends (client disconnects/crashes), ZooKeeper automatically deletes the node. Perfect for service registration.

The safest approach is to remove the failed node (consul force-leave) and add a new one. The new node will receive the log from existing healthy nodes. Never rely on a corrupted node's data.

Prepare discovers what values (if any) acceptors have already agreed to. This prevents a new proposer from overwriting an already-decided value. Phase 1 = discovery, Phase 2 = proposal.

For rarely-changing config, eventual consistency is fine. Reading from followers is faster and reduces leader load. The slight staleness (seconds) is acceptable for most configuration use cases.

The leader sends its log with prevLogIndex/prevLogTerm. The follower rejects if it doesn't match. The leader decrements and retries until it finds where logs match, then overwrites the follower's divergent entries.

A 5-node cluster needs a majority (3 nodes) to reach consensus. It can tolerate up to 2 node failures. With 3 failures, only 2 nodes remain - not a majority.

Kubernetes already runs etcd for cluster state. Many coordination needs can be met by using Kubernetes primitives (ConfigMaps, Secrets, leader election via Leases) which are backed by etcd.