# Quorum reads and writes

> With N replicas, R + W > N makes every read overlap the latest write.

Concept · Replication & partitioning · https://levelcode.org/concepts/quorums

Leaderless databases in the Dynamo tradition — Cassandra, ScyllaDB, Riak — store each key on **N** replicas and let clients choose how many must respond:

- a **write** succeeds once **W** replicas acknowledge it;
- a **read** asks replicas and waits for **R** responses, keeping the newest version.

## The overlap rule

If **R + W > N**, any set of R replicas shares at least one replica with any set of W replicas, so every read includes at least one replica holding the latest successful write.

| N | W | R | R + W > N? | Survives (writes / reads) | Character |
|---|---|---|---|---|---|
| 3 | 2 | 2 | Yes | 1 down / 1 down | Balanced default |
| 3 | 3 | 1 | Yes | 0 / 2 | Fast reads, fragile writes |
| 3 | 1 | 3 | Yes | 2 / 0 | Fast writes, fragile reads |
| 3 | 1 | 1 | No | 2 / 2 | Fastest; reads can be stale |
| 5 | 3 | 3 | Yes | 2 / 2 | More fault tolerance |

Try it: write with a low W, read with a low R, and watch the worst-case read miss the latest value. Then take replicas down.

> **Interactive: Quorum reads and writes.** With R + W > N, even the worst-case read set includes a replica that took the latest write. Lower either quorum to make stale reads possible, or take replicas down to see when operations become unavailable. Try it: https://levelcode.org/labs/quorum

## Catching replicas up

Replicas that missed a write are repaired by **read repair** (a read that sees a stale replica writes the newer value back) and **anti-entropy** (a background comparison of replicas, using [Merkle trees](https://levelcode.org/concepts/merkle-trees) to find differences cheaply).

## Caveats

- **Sloppy quorums:** some systems accept writes on stand-in nodes when the real replicas are unreachable ("hinted handoff"). Availability improves, but R + W > N no longer guarantees overlap.
- **Concurrent writes** to the same key still need a conflict rule — often last-write-wins by timestamp, which can drop a write.
- **Not linearizable by itself:** without extra steps (such as writing the newest value back to a quorum before a read returns), quorums don't give the "single copy" behaviour of linearizability (see [consistency models](https://levelcode.org/concepts/consistency-models)).

Cassandra exposes these as per-request consistency levels such as `ONE`, `QUORUM` and `LOCAL_QUORUM`.
