The model
Consensus lets a group of processes agree on an ordered sequence of decisions despite specified failures. Raft separates leader election, log replication, and safety rules into understandable mechanisms. It assumes crash failures and a communication network that can delay, drop, or reorder messages.
A concrete walk-through
Each server tracks a current term. A candidate requests votes; a server grants at most one vote per term under the protocol’s log-freshness rule. A leader appends client commands to its log and considers an entry committed once the required majority has replicated it, subject to Raft’s commit rules.
Costs and failure cases
A majority quorum tolerates some unavailable servers but cannot make progress if a majority cannot communicate. Network partitions may create temporary competing leaders in different terms, while safety rules prevent committed history from being overwritten. Consensus does not solve application-level deduplication or external side effects.
Check your understanding
In a five-server group, how many servers form a majority? What happens to write availability if three servers are mutually isolated from the remaining two?