Consistency Models: Strong, Eventual, and Causal
Explore the consistency spectrum: Linearizability, Sequential Consistency, Causal Consistency, Read-Your-Writes, and Eventual Consistency.
The Consistency Hierarchy Spectrum 📊
From strongest guarantees with highest latency to weakest with lowest latency.
01.1. The Consistency Spectrum: Why It Is Not Just "Strong vs Eventual"
In distributed systems literature, "consistency" does not refer to the 'C' in ACID transactions (which means database integrity constraints). Instead, it defines the rules governing the ordering and visibility of concurrent read and write operations across replicated nodes.
Rather than a simple binary choice between "Strong" and "Eventual", consistency forms a rich mathematical hierarchy of models, each balancing synchronization overhead against developer ergonomics.
02.2. Detailed Analysis of Key Consistency Models
1. Linearizability (Strong Consistency / External Consistency)
- Definition: The strongest single-object consistency model. Once a write completes (acknowledgment returned to the client), all subsequent reads by any client across the entire world must return that new value or an even newer one.
- Illusion: The distributed system behaves identically to a single thread executing on a single-core computer with atomic memory registers.
- Implementation: Requires distributed consensus (Raft, Multi-Paxos) or synchronized hardware reference clocks (Google Spanner TrueTime with bounded uncertainty
\epsilon). - Cost: High write latency due to inter-node network roundtrips; vulnerable to unavailability during network partitions.
2. Sequential Consistency (Lamport, 1979)
- Definition: Operations by all processes are executed in some valid sequential order, and operations of each individual process appear in this sequence in the order specified by its program.
- Difference from Linearizability: Does not enforce real-time global clock ordering. If Client A writes at 12:00:00 and Client B reads at 12:00:01 on another continent, it is legally acceptable for B to read the old value, provided all processes observe writes in the exact same logical order.
3. Causal Consistency
- Definition: If Event B is causally related to Event A (
A → B, e.g., a question followed by an answer, or a comment replying to a post), then every node in the cluster must observe Event A before Event B. - Concurrent Events: Operations that are not causally related (independent writes by different users) can be observed in different orders by different replicas.
- Implementation: Tracked via Vector Clocks or Dependency Graphs. Causal consistency is the mathematically strongest consistency model achievable in an entirely available system under network partitions (
AP).
4. Eventual Consistency
- Definition: The weakest standard model. If no new updates are made to a given key, all replicas will eventually converge to identical values.
- Behavior: Replicas accept writes locally without inter-node coordination. Reads may return stale values indefinitely while replication is in progress.
03.3. Architectural Selection Matrix
| Consistency Model | Coordination Required | Partition Tolerance (P) | Latency Impact | Real-World Database Implementations |
|---|---|---|---|---|
| Linearizability | Global (Raft / Paxos / TrueTime) | Rejects Minority (CP) | High (+20ms-50ms) | Google Spanner, CockroachDB, etcd, ZooKeeper |
| Sequential | Inter-Node Ordering | Rejects Minority (CP) | Moderate | Distributed Shared Memory, Multi-threaded JVM |
| Causal | Vector Clocks / Metadata | Fully Available (AP) | Low (< 5ms) | Git, CouchDB, Riak (with causal context) |
| Read-Your-Writes | Session-level routing | Fully Available (AP) | Minimal (< 2ms) | Amazon DynamoDB (with sticky sessions), MySQL + Proxy |
| Eventual | None (Background Gossip) | Fully Available (AP) | Microseconds | Cassandra, DynamoDB (eventual reads), DNS |
⚖️Architectural Trade-offs & Production Realities
Architectural Advantages
- Allows architects to match consistency guarantees precisely to business domain criticality
- Eventual and causal models unlock massive write throughput and sub-millisecond multi-region latency
Trade-offs & Constraints
- Weaker models force application engineers to write defensive code for stale reads, lost updates, and write conflict resolution
Git commits form a directed acyclic graph (DAG) of causal history. Developers work completely disconnected (eventual consistency) and merge causal branches deterministically using commit parent hashes.
🎯 Staff+ Engineering Takeaways
- Consistency is not a binary choice; it is a spectrum of mathematical guarantees.
- Stronger consistency requires inter-node communication and increases write latency.
- Causal consistency preserves cause-and-effect relationships without global locks.
- Eventual consistency maximizes availability and speed at the expense of temporary stale reads.
Topic Knowledge Assessment 🧠
Step through 1 scenario question to test your staff-level grasp.
Which consistency model guarantees that if a comment is posted in reply to an existing post, no user will see the reply before the original post?
How clear and staff-actionable was this system breakdown?