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 replicasdef write(key, value):
version = now()
acks = send_to_all(key, value, version)
wait_for(acks, count=W) # done when W replicas ackdef read(key):
replies = read_from_any(key, count=R) # gather R answersreturn 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?
By pigeonhole, R + W > N forces the R read replicas and W write replicas to share at least one node. Since a read returns the newest version it sees, it will see the latest write — strong consistency.
2. With N=5, which setting makes writes fast but reads potentially slow?
W=1 makes a write "done" after just one replica acknowledges (fast writes), but then R must equal N to guarantee overlap (R+W>N → R>4 → R=5), so reads consult all replicas — slow but strongly consistent.
3. What happens when R + W ≤ N?
When R + W ≤ N you can pick read and write sets that don’t overlap, so a read might only consult replicas that never received the newest write — returning a stale value until background replication propagates it (eventual consistency).
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.