Consistency Models
From strong consistency to eventual consistency and everything in between: causal, read-your-writes, and monotonic reads.
What Is a Consistency Model?
A consistency model is a contract between a distributed system and its clients. It specifies what values a read operation is allowed to return given the history of preceding writes. Choosing the right consistency model is one of the most consequential decisions in distributed systems design — it determines correctness guarantees, performance, and availability.
Consistency models form a hierarchy from strongest to weakest. Stronger models are easier to reason about but cost more in latency and availability. Weaker models are faster and more available but require application code to handle inconsistencies.
Linearizability (Strong Consistency)
Linearizability is the gold standard of consistency. Every operation appears to execute atomically at a single point in real time. From the client's perspective, the distributed system behaves exactly like a single machine: reads always return the most recently written value, and operations appear to be instantaneous.
Google's Spanner achieves linearizability globally using TrueTime. etcd (used by Kubernetes for all cluster state) is linearizable — when you write a pod configuration, every subsequent read in the cluster reflects that write. This is essential for a control plane where stale data could cause services to misbehave.
Linearizability has a performance cost
Achieving linearizability in a replicated system requires coordination (consensus protocols like Raft or Paxos) before each write or read, which adds latency. Systems like Spanner commit writes in ~10ms within a region but up to ~100ms across continents. For high-throughput, latency-sensitive applications, this can be prohibitive.
Sequential Consistency
Sequential consistency is slightly weaker than linearizability. Operations appear to occur in some sequential order that is consistent with the order seen by each individual process — but that order does not have to match real-time. All clients see the same order of operations, but that order may lag real clock time.
This distinction is subtle. Consider process A writing X=1, then B reading X (and seeing 0, then 1). With linearizability, B's read of 0 after A's write is impossible. With sequential consistency, it is allowed as long as all clients see the same global order.
Causal Consistency
Causal consistency only orders operations that are causally related. If write A happened before write B (because B was written after B's author read A), then all clients must see A before B. Concurrent, causally unrelated operations may be seen in different orders by different clients.
Consider a discussion forum. A user posts a message (write A). Another user reads that message and replies (write B). Causal consistency guarantees that all clients see the original message before the reply — the causal chain is preserved. But two concurrent top-level posts may appear in different orders for different users, which is acceptable.
Causal consistency in practice
Facebook's TAO (The Associations and Objects) graph store provides causal consistency for social graph data. When you unfriend someone and they attempt to view your private post, TAO ensures the unfriend operation is applied before the visibility check — because these operations are causally related. MongoDB 4.2+ also supports causal sessions, where reads within a session reflect all prior writes in that session.
Session Guarantees
Session guarantees are weaker consistency properties that apply within a single client's session. They are practical compromises that provide useful guarantees without requiring expensive global coordination.
| Guarantee | Definition | Example |
|---|---|---|
| Read-your-writes | A client always reads the effect of its own writes | Update profile photo → immediately see new photo |
| Monotonic reads | Once you read a value, you never read an older value | Timeline doesn't go backward as you scroll |
| Monotonic writes | Your writes are applied in the order you issued them | Post 1 appears before Post 2 if you wrote them in that order |
| Writes-follow-reads | A write that follows a read reflects the value that was read | Reply preserves context of the message it replies to |
A practical technique for providing read-your-writes: after a write, redirect the client's reads to the primary (or leader replica) for a short period. After the write has propagated to replicas, redirect reads back to replicas. This is how many web applications provide the illusion of immediate consistency without requiring a fully synchronous replication model.
Eventual Consistency
Eventual consistency is the weakest model: if no new updates are made to an object, all replicas will eventually converge to the same value. There is no bound on when convergence occurs, and there is no guarantee about the order in which a client sees values.
DNS is the classic example of eventual consistency — when you update your domain's IP address, the new value propagates to all DNS resolvers worldwide within minutes to hours, but during that window, different clients may see different IP addresses. Amazon DynamoDB (default read mode), Apache Cassandra (with consistency level ONE), and Amazon S3 (for overwrite reads) all provide eventual consistency.
Conflict resolution in eventually consistent systems
When two replicas accept concurrent writes to the same key, they must eventually agree on one value. Common strategies: last-write-wins (LWW, based on timestamp — Cassandra's default), merge (CRDTs — conflict-free replicated data types that merge automatically), and application-level resolution (the app is told about the conflict and chooses). CRDTs are used in collaborative editors like Google Docs.
Choosing the Right Consistency Model
| Use Case | Recommended Model | Reasoning |
|---|---|---|
| Bank balance / financial ledger | Linearizability | Incorrect data causes financial loss |
| User profile / settings | Read-your-writes | User must see their own changes instantly |
| Social feed / news feed | Eventual consistency | Slight staleness is acceptable for throughput |
| Comment thread ordering | Causal consistency | Replies must appear after their parent posts |
| Real-time inventory (e-commerce) | Linearizability or strong read | Overselling is a major business problem |
| DNS / feature flags | Eventual consistency | Propagation delay is expected and acceptable |
Interview Tip
In interviews, whenever you choose a database or replication strategy, follow up with: 'This database provides [consistency model], which is appropriate here because [reason]. If a user performs [action], they will see [behavior], which meets the requirement for [use case].' Connecting the abstract model to concrete user-visible behavior is what separates strong candidates from average ones.