Consistency Models (Strong, Eventual, Causal)
Consistency isn't binary — it's a spectrum. From the strictest (every read sees the latest write) to the most relaxed (replicas will eventually converge), each model trades correctness for performance. Understanding this spectrum lets you choose the weakest model your use case can tolerate — and reap the performance benefits.
The Consistency Spectrum
From Strongest to Weakest
- Strict (Linearizable): Reads always return the most recent write. As if there's one copy. Global real-time ordering.
- Sequential: All nodes see operations in the same order, but that order may not match real time.
- Causal: If operation A caused operation B, everyone sees A before B. Concurrent (unrelated) operations can appear in any order.
- Read-your-writes: You always see your own writes immediately (others might not yet).
- Monotonic reads: Once you read a value, you never see an older one on subsequent reads.
- Eventual: Given enough time without new writes, all replicas converge to the same value. No ordering guarantees in the meantime.
Strong (Linearizable) Consistency
The gold standard. Once a write completes, every subsequent read (from any client, any node) returns that value. The system behaves as if there's a single copy of data processed sequentially.
Properties
- Global ordering of all operations matching real time
- A write is visible instantly to all readers once acknowledged
- Requires coordination (consensus) between nodes → higher latency
Cost: Every write must wait for a majority of replicas to acknowledge. Cross-region latency can be 100-300ms per write.
Eventual Consistency
The most relaxed model. Replicas may temporarily disagree, but if writes stop, they will eventually converge to the same state. "Eventually" is usually milliseconds — but there's no upper bound guarantee.
Properties
- Writes return immediately (no waiting for replication)
- Reads may return stale data
- Highest availability and lowest latency
- Conflicts possible — need resolution strategy
Causal Consistency
The "sweet spot" for many applications. If event A causes event B (e.g., you post a message, then someone replies), all nodes see A before B. But concurrent, unrelated events can appear in any order.
What Counts as "Causal"?
- Read-then-write: If I read X and then write Y (influenced by X), then X → Y is causal
- Write-then-read: If I write X and then read, I must see X (or something newer)
- Transitive: If A → B and B → C, then A → C
Causal consistency is weaker than linearizable (no global time ordering) but stronger than eventual (preserves cause-effect relationships).
Timeline Comparison
Session Guarantees
Read-Your-Writes & Monotonic Reads
These are weaker than causal but stronger than eventual — often sufficient for user-facing applications:
- Read-your-writes: After you update your profile, you always see the update (even if others don't yet). Implemented by routing reads to the same replica that handled your write, or tracking write timestamps.
- Monotonic reads: If you read "balance = $80", you'll never subsequently read "balance = $100" (an older value). Prevents the disorienting experience of data going "backwards."
Real-World Analogies
- Strong consistency = Live TV broadcast: Everyone watching sees the same frame at the same moment. Expensive infrastructure (satellites, synchronization).
- Eventual consistency = Newspaper delivery: Everyone gets the same news eventually, but some houses get the paper at 6am, others at 9am. During the gap, people have different information.
- Causal consistency = Email thread: You always see a reply after the original message (causal order), but unrelated emails can arrive in any order.
Real-World Systems
🏢 Google Spanner: Global Strong Consistency via TrueTime
Spanner achieves linearizable consistency across the globe by using TrueTime — a clock system combining GPS receivers and atomic clocks in every datacenter:
- TrueTime provides a bounded uncertainty interval: "the real time is between [earliest, latest]"
- Spanner waits out the uncertainty (a few milliseconds) before committing a transaction
- This wait guarantees that if transaction T1 commits before T2 starts, T1's timestamp < T2's timestamp
- Cost: ~7ms commit latency within a region, higher cross-region. Google accepts this for banking, ad billing, etc.
🏢 Amazon Shopping Cart: Eventual Consistency in Action
Amazon's shopping cart (described in the Dynamo paper) uses eventual consistency:
- "Add to cart" always succeeds — even during failures or partitions
- Concurrent modifications may create conflicts (two replicas with different cart contents)
- Resolution: merge conflicts by union — if in doubt, keep the item in the cart (it's better to show an extra item than lose one)
- Customers occasionally see items "reappear" after deletion — an acceptable trade-off for 100% add-to-cart availability
The Cost of Consistency
Stronger Consistency = Higher Latency & Lower Availability
- Strong: Write latency = network round trip to majority of replicas. If majority is unreachable → unavailable.
- Causal: Only wait for causally-related operations. Better latency, partial availability during partitions.
- Eventual: Write returns immediately after local persistence. Always available. Lowest latency.
Rule of thumb: Use the weakest consistency your business logic can tolerate. Banking? Strong. Social media feed? Eventual. Chat messages? Causal.
Interactive: Toggle Consistency Models
Watch how 3 replicas handle writes under different models: