R plus W greater than N is the arithmetic that decides your consistency

A product catalogue runs on a three replica store. Reads are configured with R equals 1 for speed, writes with W equals 2 for durability. Somebody did the arithmetic at design time and concluded that two out of three acknowledging a write is safe.

An update to a price is acknowledged. A read a moment later returns the old price. Not consistently, roughly a third of the time.

R plus W is 3, and N is 3. Three is not greater than three, so the read set and the write set are allowed to be disjoint, and one time in three they are.

The overlap is the entire mechanism

The inequality looks like a rule of thumb and it is a geometric fact.

You have N replicas. A write goes to all of them but only waits for W to acknowledge. A read queries R of them and takes the newest answer. If the W replicas that acknowledged and the R replicas you asked share no member, the read can miss the write entirely.

Two sets drawn from N members must overlap when their sizes sum to more than N. That is all the guarantee is.

flowchart TB
    subgraph bad["N=3, W=2, R=1 (sum 3, no overlap guaranteed)"]
        B1["replica A: new value"]
        B2["replica B: new value"]
        B3["replica C: old value"]
        BR["read asks C only"] -.->|"returns stale"| B3
    end

    subgraph good["N=3, W=2, R=2 (sum 4, overlap guaranteed)"]
        G1["replica A: new value"]
        G2["replica B: new value"]
        G3["replica C: old value"]
        GR["read asks any 2"] -.->|"must include A or B"| G1
    end

    style B3 stroke:#ef4444,stroke-width:3px,color:#fff
    style G1 stroke:#4ade80,stroke-width:3px,color:#fff

With N equals 3, the useful configurations are few enough to list:

W equals 3 with N equals 3 is worth pausing on. It satisfies the inequality and it means a single replica being unavailable blocks every write, which converts a durability setting into an availability outage. Requiring all replicas is almost never what people mean when they say strong.

Where the latency actually comes from

The coordinator sends the request to all replicas and waits for the first W or R responses. So the latency is the W-th fastest, not the average and not the slowest.

That has a specific consequence: raising W from 1 to 2 does not double write latency. It changes which order statistic you are waiting on, and the jump is largest when replica latencies have a long tail, which they do when one replica is compacting or garbage collecting.

This is a small instance of a general effect. Waiting on the slowest of several is worse than the average by an amount that grows with how many you wait for, and it decides more about p99 than any single component does.

The asymmetry is what you tune. A read heavy workload wants R small and pushes W up to compensate. A write heavy one does the reverse. Cassandra lets you set this per query, which is genuinely useful: the same table can serve a dashboard at ONE and a balance check at QUORUM.

# Same table, different requirements, different consistency per statement.
session.execute(dashboard_query, consistency_level=ConsistencyLevel.ONE)
session.execute(balance_query, consistency_level=ConsistencyLevel.QUORUM)

What the inequality does not give you

This is the part that surprises people who have internalised the formula.

Quorum overlap is a statement about recency: a read will observe the most recent acknowledged write. It says nothing about what happens when two writes are concurrent.

Two clients writing different values to the same key at the same time can both reach a quorum. Both are durable. The system now holds two versions and has to pick, and the usual mechanism is last write wins by timestamp, which means the winner is decided by whichever machine’s clock was further ahead. That is a coin flip dressed as a rule, and it silently discards a valid write.

Preventing the conflict is a different operation. A compare and set, a conditional write, or a consensus round is what you need, and those cost more than a quorum because they require agreement rather than overlap. Cassandra exposes this as lightweight transactions, which run Paxos and are roughly an order of magnitude slower than a normal quorum write. That cost is the honest price of the stronger guarantee.

Overlap also does not give you monotonicity across successive reads. Two quorum reads can hit different replica subsets, and if a repair or a concurrent write is in flight, the second can return an older value than the first.

Sloppy quorums make availability better and the guarantee worse

Dynamo style systems have a feature that quietly breaks the arithmetic.

Under a sloppy quorum, if the replicas that should hold a key are unreachable, the write goes to other nodes instead, which store it as a hinted handoff and deliver it later. The write succeeds and W is satisfied.

It is satisfied by nodes that are not in the replica set for that key. A subsequent read from the actual replicas will not find it, because the hint has not been delivered yet. The inequality held and the guarantee did not, because the sets it describes were not the sets involved.

That is a deliberate trade favouring write availability during a partition, and it is the right default for a shopping cart and the wrong one for a balance. Knowing which mode you are in matters more than the numbers do.

What I would check

Write down N, R and W for each data store and check the sum. The misconfiguration is rarely exotic: it is R equals 1 chosen for latency, on a system where somebody separately chose W equals 2 for durability, with nobody comparing the two decisions.

Then ask what happens on a concurrent write, because that is the question the inequality does not answer and it is the one that produces confusing bug reports.

And check whether the store does sloppy quorums, because if it does, your effective guarantee during a partition is weaker than the configuration suggests, and a partition is exactly when you were relying on it.