FjellSystem Design Lab
Lesson 2.1• 6 min read

Consistency patterns

Weak, eventual, and strong consistency in distributed data replication.

What you will learn

  • Tell strong, eventual and weak consistency apart by when a read sees a write.
  • Name the stronger guarantees an eventually consistent store can add: read-your-writes and monotonic reads.
  • Use W+R>NW + R > N to tune a quorum store, and say what it does not promise.

The spectrum of consistency

When data is replicated across multiple physical machines or geographic regions, updates take time to propagate. A system's consistency pattern defines when a read is guaranteed to observe a previous write.

1. Strong consistency

After a write completes, every subsequent read sees it.

  • Mechanism: Data is replicated synchronously, or writes go through a consensus algorithm such as Raft or Paxos, so a write is acknowledged only once enough replicas have it.
  • Trade-off: Each write waits for other replicas, which adds latency, and if a partition stops the system reaching the replicas it needs, it must refuse requests rather than answer with stale data.
  • Where it is used: File systems and relational databases; anything that needs transactions.

2. Eventual consistency

After a write, reads will eventually see it (typically within milliseconds). Data is replicated asynchronously.

  • Stale reads: If no new updates are made, eventually all reads return the last written value. Until then, a read from a replica that has not caught up returns the old value.
  • Stronger variants: Plain eventual consistency promises nothing about the order in which a client sees values. Two common additions fix that: read-your-writes (after you update a value, you never see an older one) and monotonic reads (once you have seen a value, you never see an earlier one).
  • Where it is used: DNS and email; systems that put high availability first.

3. Weak consistency

After a write, reads may or may not see it: a best-effort approach, as in memcached.

  • Where it is used: Real-time uses such as VoIP, video chat and multiplayer games. If a phone call drops for a few seconds, you do not hear what was said while you were disconnected.

Quorums: tuning consistency with N, W and R

Dynamo-style stores replicate each item to NN nodes, wait for WW of them to acknowledge a write, and ask RR of them on a read. If

W+R>NW + R > N

then every read set overlaps every write set, so a read reaches at least one replica that has the latest acknowledged write. Werner Vogels calls this strong consistency. Daniel Abadi points out that such systems still fall short of the strict definition of consistency used in the CAP proof, even when R+W>NR + W > N, so treat the quorum rule as "reads normally see the latest write", not as a guarantee of linearizability. Raising WW or RR buys consistency at the cost of latency.

Write propagation and replication lag

Client appWriterIdle
Primary DB (leader)Strong
ACID commit
Data: v1Lag: 0ms
Replica A (us-east)Eventual
Data: v1 (Stale)Lag: 25ms
Replica B (eu-central)Eventual
Data: v1 (Stale)Lag: 80ms
Status:Ready. Click "Trigger write" to observe asynchronous replication propagation.
Figure 1: Write propagation from Primary Leader to Read Replicas with replication lag.
  • Writer Client: 1 × Clients & Users
  • Reader Client: 1 × Clients & Users
  • Primary DB (Leader): 2 × Primary Relational DB
  • Replica A (us-east): 2 × Database Read Replica
  • Replica B (eu-central): 2 × Database Read Replica
  • Writer Client sends requests to Primary DB (Leader)
  • Primary DB (Leader) sends requests to Replica A (us-east)
  • Primary DB (Leader) sends requests to Replica B (eu-central)
  • Reader Client sends requests to Replica B (eu-central)

Key takeaways

  • Strong consistency replicates synchronously or through consensus: every read sees the write, at the cost of latency and of refusing requests during a partition.
  • Eventual consistency replicates asynchronously: reads catch up, usually within milliseconds, and may be stale until then.
  • Weak consistency is best effort, which suits real-time uses such as calls and games.
  • With W+R>NW + R > N every read overlaps the latest write's replicas, so reads normally see it, but that is still not linearizability.

Sources

Adapted from The System Design Primer by Donne Martin, licensed under CC BY 4.0. Changes were made.