Vibe Engines
YouTube

Vibe Engines is free, interactive AI engineering & system design — runs in your browser. Pick a learning path

Quorum (N/R/W) Explorer

Dial the replica count and the read/write quorum sizes and see at a glance whether reads are guaranteed strongly consistent (R + W > N), how many node failures you can survive, and where you land on the latency–availability spectrum. The tunable-consistency intuition, made tactile.

Presets

write set (W=3) read set (R=3) overlap

R + W = 6 > N = 5 → strongly consistent reads. Every read overlaps the latest write.
StrongConsistency
2Write failures survivedN − W
2Read failures survivedN − R

Balanced strong consistency (majority quorums).

A quorum decides how many replicas must answer before a read or a write counts as done, and one inequality decides whether a read can miss the latest write. Stores such as Cassandra and Riak let you set those counts per request, so consistency becomes a dial. This explorer shows where a setting lands.

What it computes

Three integers describe the setup. N is the number of replicas holding each item, from 1 to 9 here. W is the write quorum, how many replicas must acknowledge a write. R is the read quorum, how many must reply to a read. The sliders keep R and W between 1 and N.

min overlap    = max(0, R + W − N)   nodes shaded as overlap
strong         = R + W > N          every read meets the latest write
writes survive = N − W              replicas that can fail
reads survive  = N − R              replicas that can fail
majority       = ⌊N / 2⌋ + 1        the Majority button

The rule is the pigeonhole principle. A write lands on some W replicas and a read collects some R; if R + W exceeds N, the two groups cannot avoid sharing a replica, and that replica holds the newest version. The ring draws the write set from the first nodes and the read set from the last, the arrangement with the least possible overlap, so a shaded overlap node is one no choice of replicas can avoid. A profile line names the trade-off: fast reads (W = N, R = 1), fast writes (R = N, W = 1), balanced strong consistency, or high availability with eventual consistency.

A worked example

The defaults are N = 5, W = 3 and R = 3.

  1. R + W = 6, which is greater than N = 5, so the verdict is Strong: every read overlaps the latest write.
  2. The minimum overlap is 6 − 5 = 1. The ring shades nodes 1 to 3 as the write set and nodes 3 to 5 as the read set, and node 3 is in both.
  3. Writes survive 5 − 3 = 2 failed replicas, and so do reads.
  4. Three is ⌊5 / 2⌋ + 1, a majority, and the profile reads Balanced strong consistency (majority quorums).

The presets keep N = 5 and move the cost between operations:

SettingR + WConsistencyWrite failures survivedRead failures survived
Majority, R = W = 36Strong22
Fast reads, R = 1, W = 56Strong04
Fast writes, R = 5, W = 16Strong40
R = W = 24Eventual33

All three presets are strongly consistent; they differ in which operation stops working first. Dropping both quorums to two buys a third survivable failure on each side, at the price of reads that can return stale data.

Assumptions and limits

  • Strict quorums. The math assumes R and W are counted among the same N home replicas. A sloppy quorum, as in the Dynamo paper and Riak, accepts writes on stand-in nodes during an outage, and a later read quorum need not meet them.
  • Completed writes only. A write still in flight may be seen by one read and missed by the next, and a write that failed after reaching fewer than W replicas is not rolled back where it landed.
  • Writes are not ordered. The inequality says nothing about two concurrent writes. Unless W > N / 2, two write sets can be disjoint, and last-write-wins can silently discard one when clocks are skewed. Fast writes (W = 1) passes the inequality and is still exposed to this.
  • No latency model. A request waits for the R-th or W-th fastest reply, so a larger quorum reaches further into the replicas' latency tail.
  • The balanced label is coarse. Any strong setting that is not an extreme preset is called majority quorums, including R = 4, W = 2 on five replicas, where the write quorum is not a majority.

How to use the result

  • Start from the failures you must ride through. To survive f replica failures on both paths with majorities, use N = 2f + 1: three replicas for one failure, five for two.
  • Prefer an odd N. Four replicas with majorities of three still survive only one failure, the same as three, while paying for an extra copy and an extra acknowledgment.
  • Lean toward the hot path, not all the way. For a read-heavy workload on five replicas, W = 4, R = 2 stays strong, lets reads survive three failures and writes survive one, where W = 5 blocks every write on the first outage.
  • Choose eventual on purpose. If a stale read is harmless, as with a view counter or a feed, R + W ≤ N is a legitimate setting. Measure replication lag so you know how stale eventual really gets.

How it works

  • N = replicas, W = acks needed to write, R = replies needed to read.
  • R + W > N ⇒ read and write sets overlap ⇒ strongly consistent reads.
  • Writes tolerate N − W failures; reads tolerate N − R failures.
  • Majority = ⌊N / 2⌋ + 1, so N = 2f + 1 replicas ride through f failures.
  • Bigger quorums = stronger guarantees but higher latency / lower availability.

Frequently asked questions

What do N, R and W mean in a quorum system?

N is the number of replicas that store each piece of data. W is the write quorum, the number of replicas that must acknowledge a write before the client is told it succeeded. R is the read quorum, the number of replicas that must reply before a read returns. The coordinator sends each request to the replicas and waits only for the first R or W answers. Tuning R and W per operation lets one cluster trade consistency against latency and availability without changing how many copies it keeps.

Why does R plus W greater than N guarantee that reads see the latest write?

It is a counting argument. A write is acknowledged by W of the N replicas and a read collects replies from R of them. If R + W is larger than N, the two groups cannot sit side by side without sharing at least R + W minus N replicas, so every read reaches at least one replica holding the newest acknowledged value. The read then returns the version with the highest timestamp or version number among its replies. With N = 5 and R = W = 3, the overlap is exactly one replica.

What R and W should I use with three replicas?

With N = 3 the usual choice is R = 2 and W = 2, which is what Cassandra calls QUORUM at replication factor 3 and the common (3, 2, 2) configuration in the Dynamo paper. R + W = 4 is greater than 3, so reads see the latest acknowledged write, and both reads and writes keep working with one replica down. R = 1 with W = 1 is faster and survives two failures, but reads can return stale data. W = 3 makes every write fail as soon as any replica is unreachable.

How many node failures can a quorum survive?

Writes keep succeeding while at least W replicas are reachable, so they survive N minus W failures. Reads survive N minus R failures. With five replicas and majority quorums of three, both survive two failed nodes. The two numbers pull against each other: raising W so that reads can use a smaller R lowers the write tolerance, and W = N means a single unreachable replica blocks every write. A failure here means a node that is down or partitioned away, not one returning corrupted data.

Does R + W greater than N make a database linearizable?

Not on its own. The overlap guarantees that a read meets the latest completed write, but a write still in flight may be seen by one read and missed by the next, and a write that failed after reaching fewer than W replicas is not rolled back. Sloppy quorums, concurrent writes resolved by last-write-wins with skewed clocks, and replicas restored from stale copies all break the guarantee. Linearizable reads and writes need synchronous read repair, and operations such as compare-and-set need a consensus protocol.

Why do quorum systems usually use an odd number of replicas?

With majority quorums an even replica count buys no extra fault tolerance. A majority of 4 is 3, so N = 4 survives one failure, exactly like N = 3, while storing one more copy and waiting on one more acknowledgment. N = 5 has a majority of 3 and survives two failures. In general N = 2f + 1 replicas tolerate f failures with majorities. An even count can still make sense with non-majority quorums, or when an extra copy is wanted for read capacity or durability.