Consensus overview

Consensus lets non-Byzantine nodes agree on a sequence of values despite crashes, delays, loss, duplication, reordering, and partitions. A replicated state machine applies the committed log deterministically.

Safety and liveness are different

Safety means the protocol never chooses incompatible values, even during arbitrary delay or partition within its fault model. Liveness means it eventually makes progress under additional assumptions.

FLP shows that a deterministic protocol cannot guarantee termination in a fully asynchronous system with even one crash failure. Practical protocols preserve safety without timing assumptions but use timeouts, stable leadership, randomness, or failure detectors for progress.

Quorums

With (N = 2f + 1) crash-fault replicas, a majority quorum permits progress with up to (f) unavailable replicas. The essential property is quorum intersection, not the word "majority" by itself. Flexible quorum systems need their own proven intersection rules.

A five-node group tolerates two crash-unavailable nodes for majority progress. It does not tolerate two Byzantine nodes; Byzantine consensus uses a different model and larger quorums.

Raft model used by the diagram

• terms impose monotonically increasing leadership epochs;
• a server votes at most once per term;
• the log up-to-date rule limits who can win;
• the leader replicates entries and advances commit index under Raft's commit rule;
• followers validate the previous log index and term before accepting a suffix;
• committed entries are applied in order by a deterministic state machine.

Raft's current-term restriction matters: a leader uses a current-term entry to safely advance commitment; "present on a majority" is not a universal shortcut for arbitrary old entries.

Reconfiguration

Never replace membership in one uncoordinated step. Raft's joint consensus uses overlapping majorities from old and new configurations during transition. Other protocols use different mechanisms; follow the protocol's proved reconfiguration procedure.

Client contract

A timeout is ambiguous: the command may later commit. Clients need stable request IDs and deduplication. A leader hint is an optimization, not proof of authority. External side effects need an idempotent/outbox design or a fencing contract.

Diagram scenarios

The animation covers election, replication and commit, a partitioned minority, follower recovery, and overlapping-quorum membership change.

Related concepts

Interactive scenarios