Strong vs Eventual Consistency

The mechanism: what does the client wait for?

The whole distinction collapses to one decision the storage engine makes on every write: does the write block until other replicas confirm it, or does it return the instant one node has stored it? Strong consistency blocks — the write is replicated synchronously and is not acknowledged to the client until enough replicas have durably applied it, so every later read is guaranteed to observe it. Eventual consistency does not block — the write is acknowledged as soon as a single node stores it, then propagated to the others asynchronously in the background, so a read that races that propagation can still see the old value.

Before going further, separate three terms that get treated as synonyms but are not the same model — this is the single most common mistake in the topic:

• Linearizability (also called atomic consistency) — the guarantee real systems mean when they say “strong”. Every operation on a single object appears to take effect instantaneously at one point between its invocation and its response, and that order respects real (wall-clock) time: if write W completes before read R begins, R must return W’s value. Spanner, etcd, and ZooKeeper aim for this.
• Sequential consistency — strictly weaker. All nodes agree on some single total order that respects each client’s own program order, but that order need not match real time. A read may legally return a value that, on the wall clock, was already overwritten a moment ago.
• Strict consistency — a theoretical ideal in which a read instantly reflects the most recent write by an absolute global clock. It presumes zero-latency propagation and is physically unachievable in a distributed system; it exists only as a textbook upper bound.

So the honest phrasing is: strong consistency in practice means linearizability; strict consistency is the impossible ideal above it; sequential consistency is a distinct, weaker model below it. The original “strict consistency or linearizability” gloss flattened three levels into one.

Eventual consistency: optimistic background propagation

Eventual consistency guarantees only that if no new writes arrive, all replicas will converge to the same value in finite time. It never promises when. A node applies a local write, returns success immediately, and ships the change to peers in the background via an anti-entropy or gossip mechanism. Because two replicas can accept conflicting writes concurrently, the system needs a convergence rule — commonly last-write-wins keyed on a timestamp or version, or a merge via vector clocks / CRDTs. The bet is that conflicts are rare or cheap to reconcile, so the system trades momentary correctness for the ability to answer every request from a nearby node without global coordination.

A worked trace: x = 10 across three regions

Take three replicas — leader US-West, plus US-East (one-way network delay ≈ 35 ms) and Europe (≈ 85 ms). The value x currently holds 5 everywhere. A client updates it to 10 on US-West at t=0. Under eventual consistency the write is acknowledged after only the leader stores it, and the two remote replicas catch up when the background replication packets arrive:

The window t=1…90 ms is the inconsistency window: two users reading the same key legitimately get different answers. Nothing is broken — the system is behaving exactly as specified. A linearizable system would instead have made the client at t=0 wait until the required replicas confirmed, so the t=30 ms Europe read could never have returned 5.

Making a read guaranteed-fresh: quorums and R + W > N

Leaderless, Dynamo-style stores buy strong per-key read freshness — a quorum read is guaranteed to observe the latest committed value — without a single leader, by forcing read and write sets to overlap. Note the precise claim: this is freshness, not linearizability. Quorum reads do not order concurrent, in-flight writes, so a later-starting read can still return an older value than an earlier one (the classic non-linearizable anomaly proved on the dedicated quorum page); making quorum reads linearizable additionally requires synchronous read-repair with write-back (ABD) or falling back to a leader/consensus. With N replicas, a write must be acknowledged by W of them and a read must collect responses from R of them. The register-level invariant is:

R + W > N ⇒ the read set and the most-recent write set share at least one node, so a read always touches a replica holding the newest version.

Concretely, take N = 3, W = 2, R = 2 (so R + W = 4 > 3):

1. t=0 — client writes x=10 (version v2) to the coordinator; it fans out to all three replicas.
2. t=40 ms — West and East have applied v2, giving W=2 acks → the write commits and the client gets OK. Europe still holds v1 (x=5).
3. A later read gathers R=2 replicas. Whatever pair it draws — {West,East}, {West,EU}, or {East,EU} — it must include West or East (the two that hold v2), because only one replica (EU) still has v1. The read compares version numbers and returns v2 → x=10.

Choosing W > N/2 additionally prevents two writes from both committing on disjoint majorities. A related knob is W = N (synchronous to every replica) for maximum read speed, versus W = 1 (fast writes, weak reads). Caveat: quorum overlap gives freshness per key; it is not full linearizability by itself — concurrent in-flight writes, sloppy quorums, and read-repair races still need care (Kleppmann details the edge cases).

Side-by-side comparison

The spectrum in between

Strong and eventual are the endpoints, not a binary. Several intermediate models fix specific pain points of plain eventual consistency without paying for full linearizability:

• Read-your-writes — a client is always shown its own latest write (even if others lag). Fixes the “I posted a comment, refreshed, and it vanished” bug; usually implemented by pinning that client’s reads to the leader or to a version watermark.
• Monotonic reads — once you’ve seen a value, you never see an older one on a later read; prevents time from appearing to run backwards when requests hop between replicas.
• Causal consistency — operations that are causally related (a reply after its parent message) are seen in that order everywhere; concurrent, unrelated operations may still be seen in any order. The strongest model still achievable with full availability.
• Bounded staleness — reads may lag, but by no more than K versions or T seconds. Turns an unbounded window into an SLA.

Many stores make this a per-operation knob (tunable consistency): Cassandra picks ONE / QUORUM / ALL per query, DynamoDB has a ConsistentRead flag, and Azure Cosmos DB exposes exactly these five named levels. That lets one system run strong reads for a balance check and eventual reads for a view counter.

When to use which — and against what

Decide per data class, not per system. The pivot question is: “If two users see different values for this key for a few hundred milliseconds, does anything actually go wrong?”

Choose strong consistency when a stale read causes a correctness or money bug: account balances, inventory decrements (selling the last unit twice), seat/room booking, idempotency keys, unique-username claims, leader election and config that other services trust. Concrete signals: the value is read-then-written under contention, or a human/downstream system takes an irreversible action on it.

Choose eventual consistency when the value is informational, high-volume, or geo-distributed and a short lag is invisible or harmless: like/view counters, feeds and timelines, product recommendations, presence indicators, DNS, CDN-cached assets, full-text search indexes.

Trade-off vs the named alternative. Strong consistency buys a mental model with zero anomalies but costs a cross-replica round trip on the critical path (tens to hundreds of ms across regions) and forfeits availability during partitions — a minority side must reject writes. Eventual consistency buys local-latency reads/writes and survival through partitions but costs you an inconsistency window and the obligation to write conflict-resolution logic (LWW silently drops a concurrent write; CRDTs avoid that but add memory and complexity). Put a number on the crossover: a US-West↔Europe replica pays ≈85 ms one-way, so a synchronous W=ALL write commits in ~170 ms+ (a full round trip), whereas an eventual W=1 write acks at local-SSD speed (sub-millisecond) and leaves an inconsistency window equal to the replication-lag SLA. That gap is why a multi-region feed absorbing on the order of 500k writes/s cannot afford a cross-region quorum on every write and must instead segment by data class — strong for the few keys where a stale read is a bug, eventual for the high-volume rest. Net rule: choose strong when a stale read is a bug; prefer eventual when a stale read is merely old news — and when unsure, reach for an intermediate model (read-your-writes or causal) before defaulting to either extreme.

Pitfalls

• “Strong” on the box rarely means linearizable everywhere. Many databases give strong consistency for single-key operations but only snapshot isolation (not serializability) for multi-key transactions, and async read replicas served behind them are eventual. Read the fine print per operation.
• Reading your own write and not seeing it. A write commits on the leader, the very next read is load-balanced to a lagging replica, and the user thinks the save failed. This is the classic eventual-consistency support ticket; fix it with read-your-writes routing, not by making the whole system strong.
• R + W > N is necessary, not sufficient, for linearizability. With sloppy quorums, concurrent in-flight writes, or last-write-wins clock skew, overlapping quorums can still surface an anomaly. Quorum overlap guarantees you touch a fresh replica; it does not by itself order concurrent writes.
• Last-write-wins silently loses data. Two concurrent writes to the same key under LWW keep exactly one by timestamp — and clock skew decides which. If both writes mattered, one is gone with no error. Use vector clocks or CRDTs when concurrent updates are expected.
• Assuming “eventually” is milliseconds. Under replica lag, GC pauses, or a saturated link, the window can stretch to seconds or minutes. If your logic assumes fast convergence, add bounded staleness or monitor replication lag as a first-class metric.
• Strong consistency masking a partition as an outage. A CP system correctly refuses writes on the minority side of a partition — which looks exactly like “the service is down” to those users. That is the design working, but it must be an explicit, expected behavior, not a 3 a.m. surprise.

Takeaways

• The dividing line is one implementation choice: synchronous replication that blocks the write until replicas commit (strong) versus asynchronous background propagation after a local ack (eventual).
• “Strong” in practice means linearizability; strict consistency is a physically impossible ideal and sequential consistency is a distinct weaker model — they are not synonyms.
• In quorum systems, R + W > N forces read and write sets to overlap so a read always hits a fresh replica — the mechanical basis for tunable freshness.
• Decide per data class: strong where a stale read is a bug, eventual where it is harmless, and reach for read-your-writes / causal / bounded-staleness in between rather than treating it as binary.

Re-authored and deepened for this guide. Sources: Martin Kleppmann, Designing Data-Intensive Applications (ch. 5 & 9, on replication, quorums, and linearizability); Werner Vogels, “Eventually Consistent” (ACM Queue, 2008); Gilbert & Lynch’s formal treatment of the CAP theorem; Herlihy & Wing on linearizability and Lamport on sequential consistency; the Google Spanner (OSDI 2012) and Amazon Dynamo (SOSP 2007) papers; Kyle Kingsbury’s Jepsen “Consistency Models” reference; and the Cassandra, DynamoDB, and Azure Cosmos DB consistency-level documentation.