A quorum is a subset of distributed processes whose participation or agreement is sufficient to make a decision safely. In a system with N processes, a majority quorum contains more than half: Q > N/2. section 10.5.2
The key guarantee is quorum intersection: any two majorities share at least one process. Shared membership preserves awareness of earlier decisions and helps prevent split-brain outcomes. section 10.5.2
A quorum connects safety, availability, and failure tolerance:
- To tolerate f failed processes while retaining decision-making ability, the system needs at least f+1 nonfailed processes and therefore at least 2f+1 total processes. section 10.5.2
- A node that cannot participate in the quorum should refrain from responding, protecting safety; after rejoining, it can respond again and restore liveness. section 3.3.2
- Replication can require acknowledgments from a quorum in the foreground while sending updates to remaining replicas asynchronously in the background. section 8.4.3
Three-process quorum
For processes {p1, p2, p3}, any two-process set forms a quorum: {p1, p2}, {p1, p3}, or {p2, p3}. Two such quorums must overlap in at least one process, so independent majorities cannot safely make unrelated decisions without shared awareness. section 10.5.2
Consensus protocols combine quorums with leaders in different ways: a leader proposes or sequences values, while quorum acknowledgments establish commitment. Raft uses this division for replicated logs. section 10.5.3 section 10.6
Table 10.2 Possible quorums for { p1, p2, p3 }
| { p1, p2, p3 } |
| { p1, p2 } { p3 } |
| { p1, p3 } { p2 } |
| { p2, p3 } { p1 } |
Compare the possible quorum subsets for three processes and inspect how their overlap supports consistency. section 10.5.2
