I use quorum as a way to explain why a system can trust an answer without waiting for every replica. The trick is choosing enough votes to balance confidence, latency, and availability.
Enough overlap creates confidence
When I talk about "Enough overlap creates confidence", I am really asking what Quorum does when a message is late, duplicated, or missing.
In a three replica system, a write might require two acknowledgements. A later read might also ask two replicas. Because the read and write sets overlap, the read has a path to see the latest accepted value.
Replica example
I use "Replica example" to keep Quorum grounded in a real system, because abstract patterns are too easy to agree with and too hard to operate.
A profile service writes a changed phone number to replicas A and B while C is slow. The write succeeds with two acknowledgements. A later read asks B and C and uses B as the newer result.
Quorum decision code
When I show "Quorum decision code", I want the code in Quorum to reveal the production decision, not just the syntax.
A simple majority rule is the smallest useful quorum for many replicated decisions:
boolean hasQuorum(int acknowledgements, int replicaCount) {
return acknowledgements > replicaCount / 2;
}The rule requires more than half the replicas to acknowledge. That majority is what lets the system choose one accepted answer instead of two competing answers.
Sequence diagram: write and read with overlap
The overlap between write and read quorums helps the reader find the accepted value.
The read write rule
- Choose quorum sizes based on correctness needs and latency budget.
- Use versions or timestamps to compare replica answers.
- Watch tail latency because quorum waits can expose slow replicas.