How can several servers keep one agreed record when a machine fails?

Keeping several copies of a service’s records can help it survive a machine failure. The difficulty is ensuring that the copies agree on the order of changes, especially when messages are delayed or part of the network becomes unreachable.

In a protocol such as Raft, an elected leader proposes entries for a log: an ordered list of commands such as changing a stored value. It sends those entries to other servers. Commitment means an entry has met the protocol's rules for becoming part of the agreed history. Replicas then apply committed commands in the same order using the same update rules, so a late message cannot simply rearrange the accepted operations. Election and log-matching rules protect that history when leadership changes.

A five-server group normally needs support from at least three servers to commit new entries. Any two groups of three overlap, which helps prevent two independent sides from safely committing conflicting histories when the protocol’s other rules are followed.

If only two of those five servers can communicate, they must wait rather than invent a competing agreed record. The system trades some availability for consistency during such a split. These guarantees concern specified crash and communication failures; malicious participants require different assumptions and additional mechanisms.