Consensus & the limits of agreement
Understand what replication promises, what consensus solves, and what a partition forces you to choose.
BY THE END, YOU CAN
- Distinguish replication, consensus, and consistency
- Reason about majority quorum availability
- Apply CAP only under its stated conditions
Diagram description: Leader → A ✓; Leader → B ✓; Leader → C …; Leader → D …; Leader + A + B = 3/5: committed
Copies need an ordering rule
Replication stores data on multiple nodes for availability, durability, or read capacity.
Copies alone do not decide which writes are authoritative when messages are delayed or leaders fail. Consensus protocols coordinate agreement on a sequence of decisions despite defined failures. Raft uses leader election and log replication to build a replicated state machine under a crash-failure model.
It does not automatically make your application invariant correct or secure against arbitrary malicious participants. The state machine still needs deterministic, valid transitions and a carefully implemented storage layer.
A majority has a cost
A five-member Raft cluster can continue making progress with a communicating majority of three, assuming the protocol's timing and availability conditions eventually hold.
Losing three members prevents new quorum-backed decisions. Quorums overlap, which is important for preserving committed history across leadership changes, but latency now includes communication and durable recording. Acknowledging a write before the required replication point changes the durability promise.
Adding replicas does not make every operation faster. Read behavior also needs a protocol: a follower read can be stale unless stronger coordination is used.
Name the consistency users require
Linearizability makes operations appear to take effect in a single order that respects real-time precedence.
Eventual consistency allows replicas to diverge temporarily while aiming to converge under its assumptions. During a network partition, CAP says a system cannot guarantee both linearizability and availability as formally defined for every request. It is not a rule to casually pick two letters in normal operation.
Relay may require strong ordering for claims while accepting stale reporting. Choose per operation, then explain what users experience when coordination becomes unavailable.
COMMON FAILURE MODE
A majority of storage nodes is not a complete consensus protocol. Elections, log rules, persistence, and reads must preserve the required guarantees.
TRY IT YOURSELF
Split a five-node cluster into groups of three and two. Identify which side may commit new quorum-backed claims, and describe the user-visible behavior on the other side.
Make the call in the laboratory.
The two-question checkpoint, your notes, and your saved progress are in the laboratory. Free, with no account.
Open in the laboratory ↗CONNECT IT TO RELAY
Write Relay's consistency contract for claiming work, retrieving status, and displaying aggregate statistics. Specify behavior during a partition.