Quorum Reads and Writes: Tuning Consistency in Distributed Databases

The Replication Dilemma

You have 3 replicas of your data for fault tolerance. A write comes in. Do you wait for all 3 to confirm? That is slow. Do you confirm after just 1? That is fast but a read from another node might return stale data. Quorums let you find the sweet spot.

The Magic Formula: R + W > N

The Quorum Overlap Principle:

  N = 3 replicas (A, B, C)
  W = 2 (write to at least 2)
  R = 2 (read from at least 2)

  Write X=5 goes to A and B:
  +-----+  +-----+  +-----+
  |  A  |  |  B  |  |  C  |
  | X=5 |  | X=5 |  | X=3 |  <-- C still has old value
  +-----+  +-----+  +-----+

  Read contacts B and C:
  +-----+  +-----+
  |  B  |  |  C  |
  | X=5 |  | X=3 |
  +-----+  +-----+
  Return X=5 (latest version wins)

  R(2) + W(2) = 4 > N(3)
  The read set and write set MUST overlap.
  At least one node in every read participated in the latest write.
  That node has the fresh data. Consistency guaranteed!

Tuning the Knobs

Configuration     Writes    Reads     Consistency   Fault Tolerance
----------------  --------  --------  ------------  ----------------
W=3, R=1 (N=3)   SLOW      FAST      Strong        Write fails if 1 down
W=1, R=3 (N=3)   FAST      SLOW      Strong        Read fails if 1 down
W=2, R=2 (N=3)   Moderate  Moderate  Strong        Tolerates 1 down
W=1, R=1 (N=3)   FAST      FAST      EVENTUAL      Stale reads possible

  The trade-off:
  - More W = slower writes, faster reads
  - More R = slower reads, faster writes
  - W=1, R=1 = fastest but eventual consistency

  Common choice: W=majority, R=majority
  With N=3: W=2, R=2
  With N=5: W=3, R=3

Sloppy Quorums and Hinted Handoff

What happens when a node is temporarily down? Strict quorums would reject the write. Amazon's DynamoDB uses a sloppy quorum: write to ANY W available nodes (even ones that do not normally hold this data). Those nodes hold the data as a 'hint' and hand it off to the correct node when it recovers. This favors availability over strict consistency.

Practical Examples

System      Default     Configurable?   Notes
----------  ----------  --------------  -------------------------
DynamoDB    Eventual    Per-read        Eventually consistent = cheap
                                         Strongly consistent = 2x cost
Cassandra   QUORUM      Per-query       ONE, QUORUM, ALL, LOCAL_QUORUM
                                         LOCAL_QUORUM for multi-DC
Riak        Quorum      Per-bucket      n_val, r, w configurable
CockroachDB Majority    No              Always uses Raft consensus

  DynamoDB trick: Use eventually consistent for reads that
  tolerate staleness (catalog browsing), strongly consistent
  for reads that need freshness (checkout inventory check).
  Same table, different read modes!

Interview Tip

When discussing distributed databases, say: 'I would configure quorum reads and writes where R + W > N to guarantee strong consistency. With 3 replicas, W=2 and R=2 means every read overlaps with the latest write. For read-heavy workloads where staleness is acceptable, I might use R=1 for faster reads. For write-heavy workloads, W=1 with R=N keeps writes fast. The key insight is that quorums let you tune consistency PER QUERY, not just per database.'

Key Takeaway

Quorum systems let you tune consistency vs performance by adjusting R (read replicas) and W (write replicas). R + W > N guarantees strong consistency. Lower values give better performance but weaker guarantees. Choose per-query based on requirements.