Quorums (R + W > N)

Problem

The earlier pieces left two extremes. Consensus gives one agreed order but funnels every write through a leader and a majority round-trip, and stops accepting writes the moment it loses quorum. Pure eventual consistency stays available through anything but lets a read return arbitrarily stale data. Real workloads sit between them and differ operation to operation: reading an account balance wants freshness, recording a click wants speed and availability, and both hit the same store.

Fixing one consistency level for the whole datastore throws away that flexibility. What you want is a dial you can turn per operation, trading freshness against latency and availability without redeploying or switching systems.

Solution

Replicate each key to N nodes with no leader, and let every operation choose how many replicas it waits for. A write waits for acknowledgment from W replicas; a read collects responses from R replicas. Set R + W > N and the read set and write set are forced to share at least one replica, so a read always touches a node that holds the most recently acknowledged write. Reconcile the versions the read collects using timestamps or vector clocks and return the newest. Set W > N/2 as well and two writes can't both succeed without overlapping, which keeps the per-key write history from forking.

The knobs map directly onto the curve:

1. R=1, W=N — fast reads, slow and fragile writes.
2. R=N, W=1 — fast writes, slow reads.
3. R=W=(N+1)/2 (such as R=W=2 with N=3) — a balanced quorum that overlaps.
4. R+W ≤ N — no guaranteed overlap, pure eventual consistency and maximum availability.

The overlap guarantee is narrower than it looks. It promises a read touches a replica carrying the latest acknowledged write, which these systems call strong consistency, but it is not linearizability: concurrent writes can both satisfy W, read repair propagates asynchronously, and there's no single real-time synchronization point. A sloppy quorum, which writes to substitute nodes when the canonical replicas are unreachable, restores availability during failures but can place the overlap on a temporary node, weakening the guarantee further. You still need version reconciliation and read repair underneath.

Tradeoffs

Implementations

Minimal pseudocode

N, R, W = 3, 2, 2                          # R + W > N → read set meets write set

def write(key, value):
    v = (value, version_for(key))          # timestamp or vector clock
    replicas = preference_list(key)[:N]
    acks = send_put(replicas, key, v)
    wait_until(len(acks) >= W)             # W durable copies before ack
    return OK

def read(key):
    replicas = preference_list(key)[:N]
    resps = send_get(replicas, key)
    wait_until(len(resps) >= R)            # R responses
    newest = reconcile(resps)              # newest version, or merge siblings
    read_repair(replicas, newest)          # push it to any stale replica
    return newest.value

The R + W > N choice forces the read and write sets to intersect; reconcile and read_repair handle the fact that intersection alone doesn't tell you which value is newest.

Dynamo-style stores

Amazon's Dynamo paper introduced the configurable (N, R, W) model alongside sloppy quorums, hinted handoff, vector-clock reconciliation, and read repair, and many later stores adopted the same knobs. The managed DynamoDB service hides them behind two read modes, eventually consistent by default and strongly consistent on request, rather than exposing R, W, and N to the caller, but the underlying mechanism is the same quorum overlap.

Cassandra tunable consistency

Cassandra sets consistency per query against a replication factor of N. ONE, QUORUM, LOCAL_QUORUM, EACH_QUORUM, and ALL each pick how many replicas a read or write must reach, so a QUORUM write paired with a QUORUM read satisfies R+W>N and sees the latest acknowledged value, while LOCAL_QUORUM keeps that overlap within one datacenter to avoid cross-region latency. Conflicts resolve by last-writer-wins on cell timestamps, and for operations that need true linearizability Cassandra offers lightweight transactions built on Paxos through the SERIAL level.

Riak

Riak exposes the quorum knobs directly: n_val for the replica count and per-request r and w, plus refinements like pr and pw to demand primary (non-fallback) replicas and dw to require durable writes. By default it uses sloppy quorums with hinted handoff for availability, tracks concurrent writes with dotted version vectors that surface as siblings, and offers CRDT data types that merge those siblings automatically instead of pushing resolution onto the client.