Stackbook Logo
data-consistencyestablished · medium operational burden

Quorum Reads and Writes

Also known as: quorum-consistency, tunable-consistency, nwr

Intent

Tune consistency and availability by requiring a configurable number of replicas to acknowledge each read and write.

Problem

In a leaderless replicated store, a write that reaches only some replicas leaves others stale. Waiting for all replicas hurts availability, while waiting for one risks reading old data. Operators need a dial between the two.

Forces

  • •Replicas can be down or slow at any time
  • •Stronger consistency costs latency and availability
  • •Different operations need different guarantees
  • •Concurrent writes can still conflict

Solution

Overview

Quorum replication lets a client choose how many replicas must participate in each operation. It underlies Dynamo, Cassandra and Riak, exposing consistency levels such as ONE, QUORUM and ALL.

How it works

Pick N, W and R so that R + W > N. For N=3, W=2, R=2 any read touches at least one replica that saw the last successful write.

N=3, W=2, R=2
write k=v2: A ok, B ok, C slow   -> success (2 acks)
read  k:    B=v2, C=v1           -> return v2 (newest version)
            read repair: send v2 to C

Versions are compared using timestamps or version vectors. The coordinator returns the newest and asynchronously repairs the laggards. Common settings:

  • W=N, R=1: fast reads, writes fail if any replica is down
  • W=1, R=N: fast writes, slow reads
  • W=R=majority: balanced default

Pitfalls

  • The overlap argument assumes a strict quorum. Sloppy quorums that write to substitute nodes can break it until hints are replayed.
  • A failed write that reached fewer than W replicas may still be returned by later reads, so failures do not mean rollback.
  • Last-write-wins on skewed clocks silently drops updates; prefer version vectors for important data.
  • Reads from R replicas multiply read load and tail latency.
  • Concurrent read-modify-write cycles still race; quorums are not transactions.

Key takeaways

  • R plus W greater than N guarantees overlap, not linearizability.
  • Use QUORUM for balanced behavior and ONE only where staleness is acceptable.
  • Pair quorums with read repair and anti-entropy to converge replicas.

✓ When to Use

  • •Leaderless stores such as Dynamo-style databases
  • •Workloads needing per-request consistency tuning
  • •Systems that must stay writable during node failures

✗ When Not to Use

  • •Needs strict linearizability or transactions
  • •Highly contended keys with frequent concurrent writes
  • •Single-leader systems that already serialize writes

Pros

  • +Tunable per operation
  • +Survives replica failures without downtime
  • +No single leader bottleneck

Cons

  • −R plus W greater than N is not full linearizability
  • −Sloppy quorums weaken the overlap guarantee
  • −Higher tail latency from waiting on slowest of quorum

Cost Profile

Infrastructure

N replicas, commonly 3

Operational

Medium: repair, tuning, monitoring

Cognitive

Medium: reasoning about stale reads

Failure Modes

  • Sloppy quorum plus hinted handoff returns stale reads

  • Concurrent writes resolved by clock produce lost updates

  • Partial write failure leaves value on fewer than W replicas but visible

Real-World Examples

Alternatives

    Related Patterns

    • replication
    • read-replica
    • consistent-hashing

    Competency Domains

    data statereliability ops