Strong vs Eventual Consistency

TL;DR. Strong consistency (linearizability) guarantees every read returns the latest committed write, at the cost of cross-region latency (2x RTT + 10 ms at p99^[1]) and reduced availability during partitions. Eventual consistency lets writes complete against a local replica in milliseconds but exposes stale reads, out-of-order observations, and conflict resolution to the application. The default recommendation for most web and mobile systems is session guarantees: per-client read-your-writes semantics at eventual-level latency. Escalate to strong only for operations where correctness is non-negotiable (money, inventory, unique constraints). The decision is per-operation, not per-database.

Learning Objectives#

• Compare strong, eventual, and session consistency across latency, availability, correctness, and cost dimensions.
• Identify the workload characteristics that demand strong consistency versus those that tolerate staleness.
• Justify a session-guarantee hybrid as the default for user-facing applications.
• Evaluate real production systems (Spanner, DynamoDB, Cosmos DB, Discord) and explain why each chose its consistency level.

The Core Trade-off#

The tension is fundamental. CAP (Brewer 2000, formalized by Gilbert and Lynch 2002^[2]) proves that during a network partition a system must choose between linearizability and total availability. PACELC (Abadi 2012^[3]) extends this: even without partitions, stronger consistency requires more coordination per operation and therefore higher latency.

Strong consistency pushes the latency floor for a cross-region write to at least two wide-area round trips for a Paxos or Raft quorum^[4]. Eventual consistency lets writes complete against the local replica in single-digit milliseconds^[5]. The metric that moves in opposite directions is coordination cost: every additional replica that must acknowledge before commit increases durability and freshness guarantees but directly inflates write latency and reduces throughput.

The practical consistency spectrum: guarantees decrease left to right while availability and throughput increase.

Side-by-Side Comparison#

The table misleads on one dimension: cost. Strong reads in DynamoDB cost 2x, but the real expense is the cross-region write latency that forces you to either accept slow writes or confine strong operations to a single region. The latency row dominates every other consideration for globally-distributed workloads.

The "programming model" row is the hidden cost of eventual. Teams that pick eventual for performance often spend months building reconciliation logic, conflict-resolution handlers, and "refresh and it works" workarounds that strong consistency would have made unnecessary^[5:1].

When to Pick Strong Consistency#

Money, inventory, or unique constraints. Double-spend, overselling the last unit, and two users registering the same username are correctness bugs. Bank ledgers, auction bids, seat reservations, and distributed locks demand a total order^[10]. Knight Capital lost approximately $440 million pre-tax on August 1, 2012 when a trading-software deployment went wrong at the NYSE open and the firm sent numerous erroneous orders into the market, an illustration of how inconsistent state across production servers can metastasize in minutes^[11].

Cross-user coordination per operation. Leader election, distributed mutex, exactly-once resource allocation. If one user's action must be visible to all others before the next action begins, you need linearizability. ZooKeeper, etcd, and Consul exist precisely for this^[12].

Stale reads are user-visible bugs. Admin dashboards that must reflect exact state. Compliance reports. Audit trails where "eventually" means "wrong."

Named systems: Spanner (6B QPS, 17 EB, five-nines availability^[13]), CockroachDB (1.7M tpmC fully serializable at 140k warehouses^[14]), FoundationDB, etcd, ZooKeeper.

When to Pick Eventual Consistency#

Latency dominates and freshness is cosmetic. View counters, like counts, trending lists, activity streams. A counter that lags by two seconds is invisible to users; tens of milliseconds of per-write coordination cost is not^[5:2].

Cross-region replication where "eventually" in seconds is the operational win. DNS, CDN cache invalidation, social-feed fan-out. DynamoDB global tables in multi-Region eventual consistency mode replicate item changes "asynchronously...typically within a second or less" between replicas, with the actual lag depending on the distance between chosen AWS Regions^[6:1].

Independent writes that do not coordinate. User preferences, analytics aggregates, logs, metrics, time-series telemetry. Writes are independent and can happen anywhere without serialization.

Partition survival matters more than exact state. Any system where availability trumps the latest value. Dynamo's shopping-cart model accepts writes on both sides of a partition and merges at heal time^[15].

Named systems: DynamoDB default reads^[8:1], Cassandra / ScyllaDB^[9:2], Riak, DNS.

The Hybrid Path#

Most production systems run session guarantees: eventual globally, linearizable-feeling per client. The four standard guarantees (read-your-writes, monotonic reads, monotonic writes, writes-follow-reads) cover the overwhelming majority of user-visible correctness expectations^[5:3].

How it works: The client carries a token (LSN, timestamp, or version vector) with each request. Reads block until the chosen replica has applied at least that version, or the client retries against a fresher replica^[16].

• Cosmos DB Session (the default): partition-scoped tokens, single-replica reads gated by LSN. Throughput equals eventual; each client sees its own writes in order^[1:3].
• DynamoDB session affinity: route the user back to their write-region until replication catches up^[6:2].
• MongoDB causal consistency (3.6+): afterClusterTime in readConcern blocks the secondary until its oplog reaches that cluster time. Only works at write concern majority and read concern majority; below that, Jepsen confirmed violations^[17].

Session tokens pin the client to a minimum LSN; stale replicas trigger a retry to a fresher one.

What session does NOT give you: cross-user invariants. User A's write is not guaranteed visible to User B on any timeline. For inventory and payments, you still need strong consistency.

Real-World Examples#

Google Spanner runs strong consistency at globe scale: over 6 billion QPS at peak, over 17 exabytes of data, and a five-nines availability SLA^[13:1]. TrueTime (GPS + atomic clocks) assigns commit timestamps with bounded uncertainty; the commit-wait mechanism absorbs that uncertainty to guarantee external consistency^[4:1]. Regional strong reads deliver single-digit ms p99^[7:1]. The cost: multi-region writes pay 2x inter-region RTT.

Discord runs eventual consistency for trillions of messages. Their ScyllaDB cluster (72 nodes, migrated from 177-node Cassandra) delivers 15 ms p99 reads^[9:3]. Messages are append-only, ordered by Snowflake IDs, and a 1-second staleness is invisible in a chat UI. The edit-plus-delete race condition that created ghost rows was fixed in the application layer, not by strengthening consistency^[9:4].

Azure Cosmos DB offers five consistency levels with Session as the default. Session reads hit a single replica (not a quorum) gated by the client's token, achieving < 10 ms p99^[1:4]. Strong consistency is blocked by default for deployments spanning more than 5,000 miles because write latency becomes prohibitive^[1:5].

Common Mistakes#

Decision Checklist#

• Does this operation require multi-party coordination (double-spend prevention, unique constraint, distributed lock)?
• Would a stale read cause a correctness bug or just mild visual confusion?
• What is the measured p99 replication lag today, and can users tolerate it?
• Would per-operation session guarantees get 90% of the UX at 10% of the latency cost?
• Is the workload globally distributed, and is linearizable cross-region actually affordable (2x RTT minimum)?
• Have you documented, per endpoint, which consistency level it uses and why?

Operation-level decision tree: start at the operation, not at the database. The same system routinely uses different levels for different endpoints.

Key Takeaways#

• The choice is per-operation, not per-database. Checkout uses strong; product catalog uses eventual; user profile uses session.
• Session guarantees (read-your-writes, monotonic reads) are the correct default for the vast majority of user-facing operations. They deliver strong-feeling UX at eventual-level cost^[1:6].
• Strong consistency costs 2x inter-region RTT per write. If you cannot afford that latency, you cannot afford strong, regardless of correctness needs.
• Eventual consistency shifts complexity from the database to the application. You will write conflict-resolution code, reconciliation jobs, and "refresh and it works" workarounds.
• Measure your replication lag. "Eventually" without a p99 SLO is not a design decision; it is a hope.

Further Reading#

• Eventually Consistent - Revisited: Werner Vogels' canonical introduction to eventual and session guarantees from the creator of Dynamo.
• Spanner: Google's Globally-Distributed Database: Corbett et al., OSDI 2012. TrueTime, external consistency, and commit wait explained.
• Consistency levels in Azure Cosmos DB: the five-level spectrum with SLA numbers and latency guarantees.
• MongoDB 3.6.4 Jepsen analysis: shows exactly when causal consistency breaks under sub-majority concerns.
• How Discord Stores Trillions of Messages: eventual consistency at chat scale, the hot-partition pattern, and the ScyllaDB migration.
• PACELC: Consistency Tradeoffs in Modern Distributed Database System Design: Abadi 2012. Why CAP alone is insufficient; latency matters even without partitions.

Flashcards#

References#