# Quorums > A quorum is the set or number of replica responses a protocol requires before an operation can succeed. Quorums help replicated systems preserve data and coordinate decisions despite failures, but their guarantees depend on which replicas participate and what protocol they follow. Source: https://sysround.com/concepts/quorums Updated: 2026-11-05 ## How quorums works Start with the replica group for one key or partition, not the entire cluster. Let N be the number of replicas, W the number that must acknowledge a write, and R the number that must respond to a read. For N = 3, W = 2 means a write succeeds after two replicas acknowledge it; specify whether acknowledgment requires durable storage. With a fixed replica set, R + W > N guarantees that every read quorum overlaps every successful write quorum. For N = 3, R = 2, and W = 2, writing to replicas A and B means any two-replica read includes A or B. This gives the read access to an acknowledged version, but the reader must still compare versions and handle concurrent or incomplete writes correctly. Requiring W > N/2 also makes write quorums overlap. Intersection alone does not serialize writes: the shared replica could accept competing values unless the protocol imposes ordering or voting rules. Read/write quorum arithmetic by itself therefore does not guarantee linearizability or make a read-modify-write operation atomic. Consensus protocols use quorum intersection together with additional rules. In Raft, elections and log replication use majorities, while terms, voting restrictions, and log rules preserve committed history across leader changes. A five-voter group needs three votes and can continue making progress with two unavailable voters, provided the remaining three can communicate and other protocol conditions hold. During a network partition, count reachable replicas for each operation. In a three-replica group split 2–1, the two-replica side can satisfy R = 2 and W = 2; the isolated replica cannot. A system may instead allow weaker reads or writes, but that changes its guarantees rather than preserving the same quorum behavior. Keep replica membership explicit. Sloppy quorums may accept responses from temporary substitute replicas, so R + W > N no longer guarantees the intended overlap. Membership changes also need a safe transition protocol; independently using majorities of an old group and a new group can create disjoint decision-making sets. ## Worked example: A three-replica key-value partition A key has replicas A, B, and C, with N = 3, W = 2, and R = 2. Initially, all store version 7. A client writes version 8; A and B persist it and acknowledge, while C is unavailable. The write succeeds. A later read from B and C receives versions 8 and 7, so the version-resolution rule selects 8 and may repair C. If the network splits into {A, B} and {C}, only the two-replica side can satisfy these thresholds. This example assumes no competing writes and a fixed replica set. Concurrent updates still need an ordering or conflict-resolution protocol; the quorum counts alone do not define one. ## Trade-offs - **Latency depends on the required responders.** An operation waits for enough qualifying responses, so larger quorums or geographically spread replicas can increase latency. - **Read and write costs can be shifted.** For a fixed replica set, increasing W can permit a smaller intersecting R, trading write latency and availability for cheaper reads. - **Partitions limit progress.** An operation that cannot reach its required quorum must wait or fail unless the system explicitly weakens its guarantees. - **Acknowledgment is not automatically durability.** Surviving crashes requires defining what replicas persist before acknowledging and placing copies across relevant failure domains. - **Intersection is not a complete consistency protocol.** Concurrent writes, version selection, incomplete operations, and atomic updates still require explicit protocol rules. - **Repair and reconfiguration add complexity.** Lagging replicas need catch-up or repair, while membership changes must preserve the intersections required for safety. ## When to use it in a system design interview - You are designing a replicated key-value store and must define read consistency, write acknowledgment, and behavior during partitions. - You need to explain whether an acknowledged log append or queue message survives a leader failure. - A control plane needs one authoritative leader or configuration despite network partitions. - The interviewer asks how many replica failures the system can tolerate or whether a region can keep serving independently. ## How to bring it up in the interview - Define the replica group and acknowledgment contract first: “Each partition has three replicas across three failure domains, and writes wait for two durable acknowledgments.” Expect follow-up questions about correlated failures and recovery. - Show the intersection math with a concrete replica set, then state its limits: R + W > N provides read/write overlap, not automatic linearizability. - Separate leaderless read/write quorums from consensus majorities. If you need ordered decisions or atomic conditional updates, explain the leader, consensus, or concurrency-control mechanism that supplies them. - Walk through a partition and a timeout. Say which side can proceed, and explain that a timed-out write may still have taken effect, so retries need an idempotency or deduplication strategy. - Be ready to discuss stale replicas, safe membership changes, and read paths after failover; a majority-committed log does not make every follower read current. ## Common mistakes - Claiming that R + W > N alone guarantees linearizable reads and writes. - Treating a quorum as a majority of all machines in the cluster instead of the relevant replica or voting group. - Assuming overlapping write quorums prevent conflicting updates without ordering, voting, or conditional-write rules. - Applying fixed-set quorum math to sloppy quorums or independently changed replica memberships. - Treating a timeout as proof that a write failed, or treating an acknowledgment as proof of disk persistence without defining the contract. ## Interview questions where it comes up - [Design a distributed key-value store](https://sysround.com/questions/design-key-value-store): Read/write quorum choices determine replica overlap, partition availability, and the assumptions needed for version resolution and recovery. - [Design a distributed message log like Kafka](https://sysround.com/questions/design-kafka): Replication and election quorums help define when an append is committed and which acknowledged records must survive leader failover. - [Design a distributed message queue like RabbitMQ](https://sysround.com/questions/design-message-queue): Quorum-backed replication helps preserve acknowledged messages and queue state across replica failures. - [Design a control plane for a distributed database](https://sysround.com/questions/design-database-control-plane): Quorum-based authority is central to safe leader election and failover, alongside fencing that prevents an old leader from continuing to act. ## FAQ ### What is a read/write quorum, and why must R + W be greater than N? A read quorum requires R replica responses, and a write quorum requires W acknowledgments from a replica group of size N. If R + W > N, those sets must overlap when they use the same fixed replica group. That overlap lets a read encounter an acknowledged write, but version handling and concurrent operations determine the final consistency guarantee. ### Is quorum consensus the same as a read/write quorum? No. A read/write quorum specifies how many replicas participate in storage operations, while consensus establishes agreement on decisions or an ordered history. Consensus protocols use intersecting quorums plus rules about voting, ordering, and recovery; merely collecting a majority of write acknowledgments is not a complete consensus protocol. ### How many failures can a quorum tolerate? A majority-based consensus group with 2f + 1 voters can continue making progress with f unavailable voters if the remaining majority can communicate and the protocol's other conditions hold. For a read/write configuration, reads need at least R reachable replicas and writes need at least W. These are progress limits, not a blanket guarantee against data loss from permanent or correlated failures. ## Related concepts - [Database replication](https://sysround.com/concepts/replication) - [Consensus algorithms](https://sysround.com/concepts/consensus) - [Linearizability](https://sysround.com/concepts/linearizability) - [CAP theorem](https://sysround.com/concepts/cap-theorem) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.