Quorum

A quorum is the minimum number of nodes that must agree on an operation (read or write) for it to be considered successful, ensuring consistency without requiring all nodes to participate.

What It Really Means

In a replicated system with N nodes, you have a choice: wait for all N nodes to acknowledge a write (slow but consistent), or accept acknowledgment from just one node (fast but risky). A quorum is the middle ground — require a majority to agree.

The fundamental insight is the overlap principle. If you write to W nodes and read from R nodes, and W + R > N, then at least one node in any read set must have the latest write. This guarantees that reads see the most recent data — you get consistency without requiring all nodes to be available.

For a 3-node cluster: W=2, R=2. You write to 2 out of 3 nodes, and read from 2 out of 3 nodes. No matter which 2 you read from, at least one of them has the latest write. If you read from the one that does not have it, the other one does, and the system can return the newer value.

This is how leaderless databases like Cassandra and DynamoDB provide tunable consistency without a single leader bottleneck.

How It Works in Practice

The W + R > N Formula

With N replicas, W write acknowledgments required, and R read acknowledgments required:

• W + R > N: Strong consistency (reads overlap with writes)
• W + R <= N: Eventual consistency (reads may miss recent writes)

Common configurations for N=3:

Apache Cassandra

Cassandra lets you set consistency level per query:

With a replication factor of 3 and QUORUM for both reads and writes, W=2 and R=2, giving strong consistency.

Amazon DynamoDB

DynamoDB uses quorum-based replication internally. By default, reads are eventually consistent (R=1). You can request strongly consistent reads, which read from a quorum and return the latest write.

Raft Consensus

Raft uses quorum for both leader election and log replication. A leader must replicate a log entry to a majority of nodes before committing it. With 5 nodes, the leader needs 3 acknowledgments (including itself) to commit.

Implementation

Trade-offs

Advantages

• Tunable consistency: Adjust W and R per operation based on requirements
• No single leader bottleneck: Any node can accept writes (leaderless)
• Fault tolerant: System operates as long as quorum nodes are available
• Low latency: Do not need to wait for all nodes, just a majority

Disadvantages

• Reduced availability: With N=3 and W=2, losing 2 nodes means writes fail
• Conflict resolution complexity: Concurrent writes to different nodes require timestamps, vector clocks, or CRDTs
• Read repair overhead: Stale replicas must be updated, consuming bandwidth
• Sloppy quorums weaken guarantees: If the designated nodes are unavailable and writes go to substitute nodes, W+R>N no longer guarantees overlap

Sloppy Quorum

In a sloppy quorum (used by DynamoDB), if the designated replicas are unavailable, the write goes to other nodes temporarily. This improves availability but breaks the overlap guarantee. The data is "handed off" to the correct nodes once they recover.

Common Misconceptions

• "Quorum guarantees linearizability" — Quorum reads and writes guarantee you see the latest write, but they do not guarantee linearizability without additional coordination. Two concurrent reads might see different values if a write is in progress.
• "W=1 means data is on only one node" — W=1 means the write returns after one acknowledgment. The data still replicates to other nodes asynchronously.
• "Quorum is only for databases" — Quorum consensus is used in leader election, distributed locks, and configuration management (etcd, ZooKeeper).
• "N=5 is always better than N=3" — More replicas mean more storage cost, more replication traffic, and higher write latency (quorum of 3 vs quorum of 2). Choose N based on fault tolerance requirements.
• "Read repair is sufficient for anti-entropy" — Read repair only fixes data that is actually read. Keys that are never read remain stale forever. You also need background anti-entropy processes (like Cassandra's Merkle tree-based repair).

How This Appears in Interviews

Quorum is essential knowledge for distributed systems interviews:

• "Design a key-value store with tunable consistency" — Explain N, W, R parameters. Show how W+R>N gives strong consistency and W+R<=N gives eventual consistency.
• "Cassandra uses QUORUM consistency. What does that mean?" — For a replication factor of 3, QUORUM is 2. Reads and writes each require 2/3 nodes, guaranteeing overlap.
• "What happens when a node goes down in a 3-node cluster with W=2?" — Writes still succeed (2 of 2 remaining nodes). If a second node fails, writes fail (only 1 node, less than W=2).
• "How do you handle conflicts in leaderless replication?" — Last-write-wins (LWW) with timestamps, vector clocks for causal ordering, or CRDTs for automatic conflict resolution.

See our interview questions on distributed systems for more practice.

Related Concepts

• Replication — quorum is a replication consistency strategy
• Consistent Reads — quorum reads are one way to achieve consistent reads
• Leader Election — Raft uses quorum for voting
• Merkle Trees — used for anti-entropy repair alongside quorum
• Partition Tolerance — quorum behavior during network partitions
• System Design Interview Guide
• Algoroq Pricing — practice distributed systems concepts