Consistency Trade-offs: CAP, PACELC and Quorums

You cannot have everything during a partition

The CAP theorem says that when a network partition separates nodes, a distributed data store must choose between consistency (every read sees the latest write, or gets an error) and availability (every request gets a non-error response, possibly stale). Partitions are not optional in real networks, so the choice is really C or A during a partition. PACELC extends this: if there is a Partition, choose Availability or Consistency; Else, in normal operation, choose lower Latency or stronger Consistency. Many systems let you tune per request with quorums: with N replicas, a write waits for W acknowledgements and a read queries R replicas; if R + W > N, every read overlaps at least one replica with the latest write. Choose by business need: account balances and inventory counts usually need strong consistency; like counts, feeds and recommendations tolerate eventual consistency.

Quorum settings with three replicas

Tuning R and W trades latency and availability against consistency.

N = 3 replicas

W=3, R=1   strong reads, fast reads; any one replica down blocks writes
W=2, R=2   R+W=4 > 3: reads see latest write; tolerates one replica down
W=1, R=1   fastest, most available; reads may be stale (eventual consistency)

rule of thumb: R + W > N  -> read and write sets overlap -> no stale reads
               (assuming no concurrent failures or sloppy quorums)

Consistency is a product decision

Ask the business what happens if two users see different values for a few seconds. "Two people buy the last ticket" and "the like count is off by one" deserve very different designs.

Quick check: With N = 3 replicas, which setting guarantees reads overlap the latest write?

• W = 1, R = 1
• W = 1, R = 2
• W = 2, R = 2
• W = 0, R = 3