Strong vs Eventual Consistency Explained

Strong consistency — specifically linearizability — guarantees that every read returns the most recent acknowledged write, and that all clients observe operations in one single, real-time-consistent order. It behaves as if there were only one copy of the data, even though there are several. Eventual consistency guarantees only that if no new writes arrive, replicas will eventually converge on the same value. It makes no promise about how stale a read can be or in what order concurrent writes resolve.

Between those two extremes sit named, checkable models: read-your-writes (a client always sees its own prior writes), monotonic reads (a client never sees an older value after a newer one), and causal consistency (writes that causally depend on each other are seen in that order by everyone). These are not marketing terms — each has a precise guarantee and a mechanism that provides it, and mixing them up is how teams promise more than their database delivers.

This is a different axis from the CAP theorem, which asks what a system does during a network partition. Consistency model choice matters even when the network is healthy, because it decides how fast a replica must catch up before a read is allowed to use it. The database selection guide applies those guarantees to workload and product choices.

Linearizable writes to u-42/profile go through a single point of agreement — a leader elected by a consensus protocol such as Raft or Paxos, or a quorum that every read and write must intersect. A write is acknowledged only after a majority of replicas persist it; a read must also reach a majority (or the current leader) so it cannot return a value older than the last acknowledged write. Quorum consistency requires W + R > N, where N is the replica count, W is the number of replicas a write waits for, and R is the number of replicas a read consults.

The cost is latency and availability. Every write waits for a cross-replica round trip, so tail latency rises with the slowest replica in the quorum, and a network partition that strands the leader — or leaves no majority reachable — stops writes rather than serving a possibly stale one. This is the direct trade CAP describes: correctness under partition is purchased with unavailability, not the other way around.

Strong consistency is worth that cost when a stale read causes real harm: account balances, inventory counts that gate checkout, or a leader-election lock. It is not free insurance — using it for data that tolerates staleness (a follower count, a lastSeenAt timestamp) pays the latency tax for a guarantee nothing downstream needs.

An eventually consistent write to u-42/profile acknowledges after the local (or single) replica accepts it, then propagates asynchronously to the other regions. The write returns fast because it never waits for a cross-region round trip. The guarantee is weak on purpose: if writes stop, every replica will converge to the same value — but there is no bound on how long convergence takes, and no promise about which value wins when two regions write concurrently.

Conflict resolution has to be explicit. Last-write-wins (LWW) picks the write with the highest timestamp or version and silently discards the other — simple, but it loses data whenever clocks skew or two writes are truly concurrent. Version vectors track which replica saw which prior version, so the system can detect a genuine conflict instead of guessing. CRDTs (conflict-free replicated data types) go further: they pick data structures — counters, sets, registers — whose merge function is provably associative and commutative, so any merge order converges to the same result without a human resolver.

Eventual consistency is the right default for data where staleness is cheap and availability is not: view counts, presence indicators, product recommendations, most of a social feed. It becomes a bug source the moment a client assumes its own write is immediately visible.

Most “eventual consistency is broken” bug reports are actually a missing read-your-writes guarantee — the client's own next read hits a replica that has not received its own prior write. That is fixable without paying for global linearizability: route a client's reads to the replica that served its last write (sticky sessions), or have the client attach the version/timestamp of its last write and have the read replica wait until it has replicated at least that version before answering.

Monotonic reads solves a related complaint — a client seeing a newer value, then an older one, because two reads landed on different replicas with different lag. Pinning a client to one replica for the duration of a session fixes this too, at the cost of that replica becoming a single point of degraded latency for that client.

Causal consistency is the strongest of these practical middle grounds: it guarantees that if write B was made after seeing write A, every client that sees B also sees A first. It requires tracking causal dependencies (typically via vector clocks or hybrid logical clocks) rather than just ordering by wall-clock time — and it is usually enough to make a comment-after-a-post or a reply-to-a-message feel correct without the cost of full linearizability.

Trigger. A user in eu-west updates their display name to “Alex.” Two seconds later, on a flaky connection, a stale mobile client retries an older, already-superseded edit — “Alexandra” — that never got acknowledged the first time. Both writes land on different regional replicas within the same second, and the store resolves conflicts with last-write-wins on server receive time. Symptom: the profile settles on “Alexandra,” and the user reports their save “didn't work,” even though it succeeded and was later silently overwritten.

Root mechanism. LWW compares timestamps assigned at each replica's receive time, not at a global, causally ordered clock. The retried request was logically older but arrived later at a replica with laggy clock sync, so it won the timestamp comparison. Nothing errored — the conflict was resolved exactly as designed, just not as the user expected.

Evidence. Both writes exist in the replication log with distinct request IDs and client timestamps; comparing client-side timestamps (not receive time) shows the retried write was causally older. Recovery: replay writes in client-timestamp order for the affected key, or restore from the write-ahead log. Prevention: move conflict detection to version vectors so genuinely concurrent writes surface for resolution instead of silently dropping one, make the mobile client idempotent (dedupe by request ID so a stale retry cannot resubmit), and use hybrid logical clocks instead of raw receive time for ordering.

Start from one question: what breaks if this specific read is stale? If the answer is money, safety, or a gating decision (checkout inventory, a distributed lock, a leader flag), pay for strong consistency on that read path and keep the blast radius small — most systems do not need every table linearizable, only the ones with these properties.

If staleness is cheap but slow writes or write unavailability are not — social counters, presence, recommendations, most denormalized read models — default to eventual consistency, and pick an explicit conflict-resolution strategy (CRDT for pure counters/sets, version vectors when losing data is unacceptable, LWW only when you have accepted that a concurrent write may be silently dropped).

Before reaching for full linearizability to fix a stale-read complaint, check whether the actual complaint is read-your-writes or causal ordering — both are solvable at a fraction of the latency cost. Document the chosen guarantee per data type, not per database, because one storage engine often offers several consistency levels through different read/write options.