Quorum: The Formula for Consistency

The Problem

In a Leaderless system (like DynamoDB or Cassandra), you write to multiple nodes at once. But networks are flaky. What if you write to 3 nodes, but only 2 receive it? And then you read from the 3rd node? You get Old Data.

The Formula: R + W > N

To guarantee Strong Consistency (that you always read the latest write), you must obey the Quorum Formula:

R + W > N

  • N: Total number of replicas (e.g., 3).
  • W: Write Quorum (How many nodes must confirm a write for it to be successful).
  • R: Read Quorum (How many nodes you must read from to get the data).

Why does it work?

If R + W > N, there must be an overlap of at least one node. That one node has the latest data. The database uses timestamps (or Vector Clocks) to detect which version is newer and returns it.

Common Configurations (N=3)

  1. Strong Consistency (Balanced)
    • N=3, W=2, R=2 -> 2 + 2 = 4 > 3. (Consistent!)
    • This is the standard default. It tolerates 1 node failure.
  2. Fast Writes (Eventual Consistency)
    • N=3, W=1, R=3 -> 1 + 3 = 4 > 3. (Consistent, but slow reads).
    • N=3, W=1, R=1 -> 1 + 1 = 2 < 3. (Not Consistent!).
    • W=1 is super fast but risky.

Interactive Demo: Quorum Calculator

Tune the parameters to see if your system is Consistent or Eventual. Also observe the Latency Cost. Higher W/R = Higher Latency.

3
2
2
2 + 2 > 3
STRONG CONSISTENCY
Est. Latency: Medium
● Write ● Read ● Overlap

Deep Dive: Sloppy Quorum & Hinted Handoff

Sometimes, Availability is more important than Consistency (e.g., Amazon Shopping Cart). If you need W=2 but only 1 node is online, a Strict Quorum would fail the write (Error 503). Sloppy Quorum says: “It’s okay. Write to the 1 online node, and write the 2nd copy to a temporary neighbor (Hinted Handoff).”

Feature Strict Quorum Sloppy Quorum
Availability Lower (Needs W replicas online) Highest (Accepts writes anywhere)
Consistency Strong (if R+W>N) Eventual (Data hidden in handoff)
Use Case Banking, Auth Shopping Carts, Likes

Deep Dive: Conflict Resolution (Vector Clocks)

In a Leaderless system with Eventual Consistency, two users might write to the same key at the same time on different nodes. Who wins?

  1. Last Write Wins (LWW): Use the timestamp. (Simple, but risky—clock skew can cause data loss).
  2. Vector Clocks: Track “Version Vectors” (e.g., [A:1, B:2]). If versions conflict (branches), keep BOTH versions and ask the client to resolve it (like a Git Merge Conflict).