Systems · Consistency

R plus W.

Dynamo-style stores don’t force you to choose strong or eventual consistency once — they let you tune it per operation. With N replicas of a key, a write is acknowledged once W replicas store it, and a read gathers answers from R replicas and returns the newest. The one rule that decides everything: if R + W > N, the read set and the write set are forced to overlap in at least one replica — so a read is guaranteed to see the latest acknowledged write (strong consistency). Let R + W ≤ N and the sets can miss each other, so a read may return a stale value. Slide R and W, then write and read, and watch the overlap decide.

tunable consistency · R+W>N ⇒ read sees latest write · latency vs consistency, per operation
N

The replication factor — how many copies of each key exist.

W

Write quorum — how many replicas must acknowledge a write before it’s "done".

R

Read quorum — how many replicas a read consults, returning the newest answer.

the rule

R + W > N forces read and write sets to overlap → strongly-consistent reads.

quorum.js — overlap or go stale
Ready
N=5 replicas of a key. A write updates the W left-most replicas; a read consults the R right-most and returns the newest version it sees. Adjust R and W, then write and read. R+W>N means the sets overlap.
3+3
R + W
0
overlap
last read

How it works

The guarantee is pure pigeonhole. A write is stored on some set of W replicas; a read consults some set of R replicas. If R + W > N, those two sets can’t fit into the N replicas without sharing at least one — so the read is guaranteed to touch a replica that has the latest write, and by returning the newest version it sees, it returns that write. If R + W ≤ N, you can choose disjoint read and write sets, and then a read might consult only replicas that never saw the new write, returning a stale value until background replication catches up. This is why the two common presets are W=N, R=1 (fast reads, slow durable writes) and R=N, W=1 (fast writes, slow reads), and why R=W=⌈(N+1)/2⌉ (a majority each) balances the two while still guaranteeing overlap.

1

Pick N, R, and W

N replicas hold each key. Choose how many must acknowledge a write (W) and how many a read consults (R). Higher W means more durable but slower writes; higher R means fresher but slower reads.

2

Write reaches W replicas

A write is considered successful once W replicas store the new version. The other N−W get it later via background replication.

3

Read gathers R replicas, takes the newest

A read asks R replicas and returns the highest version among them. Whether that’s the latest depends on whether the read set overlaps the write set.

R + W > N guarantees freshness

When R + W > N the read and write sets must overlap, so a read always sees the latest acknowledged write. When R + W ≤ N, reads can be stale until replication catches up.

Strong reads
R + W > N
Fast reads
W=N, R=1
Fast writes
R=N, W=1
Balanced
R=W=majority

The code

# quorum read/write over N replicas def write(key, value): version = now() acks = send_to_all(key, value, version) wait_for(acks, count=W) # done when W replicas ack def read(key): replies = read_from_any(key, count=R) # gather R answers return max(replies, key=lambda r: r.version) # newest wins # if R + W > N, the R read replicas and W write replicas must # share at least one node -> the read sees the latest write.

Quick check

1. What does R + W > N guarantee?

2. With N=5, which setting makes writes fast but reads potentially slow?

3. What happens when R + W ≤ N?

FAQ

What is a quorum in distributed systems?

The minimum number of replicas that must participate in an operation. With N copies, a write quorum W is how many must ack a write and a read quorum R how many a read consults. Tuning R and W trades off consistency, availability, and latency; R + W > N guarantees reads see the latest write.

Why does R + W > N give strong consistency?

Pigeonhole: the R read replicas and W write replicas can’t both fit in N without sharing one when R + W > N. That shared replica has the latest write, and a read returns the newest version it sees — so it returns that write. Below the threshold the sets can be disjoint and miss recent writes.

What are common R/W configurations?

W=N, R=1: fast reads, slow/durable writes. R=N, W=1: fast writes, slow reads. R=W=majority balances both while keeping R+W>N (a common default). Lower R+W (≤N) trades consistency for latency and availability — eventual consistency.

How do quorums relate to CAP and eventual consistency?

Quorum tuning exposes the CAP trade-off as a dial (Dynamo, Cassandra, Riak). R + W > N leans consistent (CP-like); relaxing it leans available and low-latency but allows stale reads (AP-like, eventual). Set per operation, one system can serve both consistency modes.

Keep going

Finished this one? 0 / 49 Labs done

Explore the topic

See this alongside everything else on the same subject — handbooks, system designs, challenges and tools, in one place.

More Labs

Cite this page

Reference it in your work, paper or an AI's context window.

APASingh, S. (2026). The Quorum Dial. Vibe Engines. https://vibeengines.com/lab/quorum-simulator
MLASingh, Saurabh. “The Quorum Dial.” Vibe Engines, 2026, vibeengines.com/lab/quorum-simulator.
BibTeX
@online{vibeengines-quorum-simulator,
  author       = {Singh, Saurabh},
  title        = {The Quorum Dial},
  year         = {2026},
  organization = {Vibe Engines},
  url          = {https://vibeengines.com/lab/quorum-simulator}
}