Consistency Models: What Readers Actually See

TL;DR: A consistency model is a contract between a storage system and its clients about which orderings and visibility outcomes are allowed¹. Linearizability behaves like a single machine but costs coordination on every operation. Eventual consistency is cheap but exposes stale reads, out-of-order updates, and divergent views. Causal consistency, the strongest model that remains totally available under partitions², is the sweet spot for most human-facing applications. The four client-centric guarantees (read-your-writes, monotonic reads, monotonic writes, writes-follow-reads) describe what “acceptable weirdness” looks like from one user’s point of view³.

Learning Objectives

After this module, you will be able to:

• Explain why consistency is a reader-side property, not a writer-side one
• Distinguish linearizability, sequential consistency, causal consistency, and eventual consistency with formal precision
• Describe the four client-centric session guarantees and map them to UX behaviors
• Untangle ACID-C, CAP-C, and replica consistency as three distinct concepts
• Identify write skew under snapshot isolation and know when to upgrade to serializable
• Translate a business requirement into a consistency-model choice with concrete trade-offs

Intuition

You and a friend are watching a football match on different streaming services. You see the final goal, text your friend “Germany won!”, and they refresh their stream. They still see the match in progress. Did the system break?

Not necessarily. Your friend’s stream is reading from a replica that has not yet received the update. The system never promised real-time ordering across different clients reading from different replicas. It only promised that eventually, all replicas converge.

Now imagine a bank account with two ATMs. You deposit $500 at ATM-A, walk across the street, and check your balance at ATM-B. If ATM-B shows the old balance, you panic. Banks cannot tolerate this. They need every read to reflect every completed write, which is linearizability, and it costs coordination latency on every operation.

A consistency model formalizes which of these outcomes a system allows and which it forbids. It is a contract with readers. The trap: engineers discuss consistency in terms of writers (“the write committed to two replicas”). Flip your mental model to the reader’s side. A consistency model tells you what is acceptable weirdness for someone reading the data.

Theory

Why “consistency” is overloaded

The word “consistency” means three different things in distributed systems, and conflating them is the single biggest source of confusion in design reviews⁴:

1. ACID-C: application-level invariants hold after every transaction (foreign keys, uniqueness constraints). This is about your schema, not your replicas.
2. CAP-C: specifically linearizability. Every read returns the most recent write. This is about replicas agreeing in real time.
3. Replica consistency: the general family of models (sequential, causal, eventual) describing what readers see across replicated state.

Kleppmann argues that CAP’s “CP vs AP” classification is so misleading that he cannot unambiguously classify any real system, including ZooKeeper (which is not linearizable by default for reads unless you call sync)⁴. When someone says “our database is strongly consistent,” ask: do you mean linearizable? Serializable? Read-your-writes? The answer changes the architecture.

The consistency hierarchy

Consistency models form a hierarchy from strongest (most constrained, most expensive) to weakest (most permissive, cheapest):

flowchart TD
    SS["Strict Serializable<br/>(Spanner, etcd)"] --> L["Linearizable"]
    SS --> Ser["Serializable"]
    L --> Seq["Sequential"]
    Seq --> Ca["Causal"]
    Ca --> PRAM["PRAM / Session"]
    PRAM --> RYW["Read-your-writes"]
    PRAM --> MR["Monotonic reads"]
    PRAM --> MW["Monotonic writes"]
    Ca --> BS["Bounded Staleness"]
    BS --> E["Eventual<br/>(DynamoDB default, Cassandra)"]

Linearizability (Herlihy and Wing, 1990): every operation appears to take effect atomically at some point between its invocation and response, in a total order consistent with real-time¹. If operation A completes before B begins, every observer sees A before B. The system behaves like a single machine. Costs: quorum coordination on every write, at least one cross-region round trip for global linearizability (~150 ms across continents), and unavailability during partitions (CP in CAP)⁴.

Sequential consistency (Lamport, 1979): a single global total order exists that all processes agree on, and each process’s program order is preserved, but the global order need not match real time⁶. A write can appear delayed arbitrarily. CPU memory models like x86-TSO are close to sequentially consistent but strictly weaker: they allow store-to-load reordering via the store buffer (a store followed by a load to a different address can be reordered)⁷. They are not linearizable either.

Causal consistency: operations that are causally related (A happened-before B, or B read A’s result) are seen in the same order at every replica. Concurrent operations may appear in any order⁸. This is the strongest model that can be totally available under partitions².

Eventual consistency: if writes stop, all replicas eventually converge. No bound on how long “eventually” takes⁹. Readers can see stale data, out-of-order updates, and divergent views.

Session guarantees

The hierarchy above is data-centric: it describes what all replicas collectively guarantee. Client-centric consistency describes what a single session observes, which is often what end-user software actually cares about³:

1. Read-your-writes (RYW): after you write a value, your subsequent reads see that value or a newer one. Without this, you update your profile photo, refresh, and see the old one.
2. Monotonic reads: if you read value v1, later reads return v1 or newer, never older. Without this, your inbox shows 10 emails, then 9, then 10 again.
3. Monotonic writes: your writes are applied in the order you issued them. Setting your name to “Alex” then “Alexandra” never results in “Alex” being the final state.
4. Writes-follow-reads: if you read a value and then write, your write is ordered after the value you read. Your reply to a post is never visible without the post itself.

These four are orthogonal. A system can provide any subset. “Session consistency” typically means all four within a logged-in session. Cosmos DB’s default “Session” level delivers exactly this with a client-cached session token¹⁰. MongoDB’s causal sessions use a hybrid logical clock carried in the client session¹¹.

ACID isolation levels

Isolation levels are orthogonal to replica consistency but often confused with it. They describe what concurrent transactions within a single database see of each other’s partial work¹²:

flowchart TD
    RU["Read Uncommitted<br/>(dirty reads allowed)"] --> RC["Read Committed<br/>(Postgres default)"]
    RC --> SI["Snapshot Isolation<br/>(Postgres 'Repeatable Read')"]
    SI --> S["Serializable<br/>(SSI in Postgres 9.1+)"]
    S --> SS["Strict Serializable<br/>(Serializable + Linearizable)"]

The critical subtlety: snapshot isolation is not serializable. Oracle’s “serializable” mode is actually snapshot isolation and permits write skew¹². Two on-call doctors each read “someone else is on call,” each mark themselves off, and nobody is on call. Only true serializable (SSI) prevents this¹³.

Eventual consistency and conflict resolution

When replicas accept writes independently (AP systems), conflicts are inevitable. Three resolution strategies dominate:

Last-writer-wins (LWW): the write with the highest timestamp wins. DynamoDB Global Tables in MREC mode (the default) use this for cross-region replication¹⁶. Simple but dangerous: with clock skew, a causally-later write can have a lower timestamp and be silently discarded.

Vector clocks: each write carries a vector of per-replica counters tracking causal history¹⁷. Concurrent writes are detected (neither dominates) and surfaced to the application for merge. Amazon’s original Dynamo shopping cart used this approach¹⁸.

CRDTs (Conflict-free Replicated Data Types): data structures designed so that concurrent operations commute and merge deterministically without coordination¹⁹. A G-Counter, for example, maintains per-replica counts and merges via element-wise max:

flowchart LR
    subgraph R1["Replica 1"]
        A1["{A:3, B:1}<br/>local total = 4"]
    end
    subgraph R2["Replica 2"]
        A2["{A:2, B:4}<br/>local total = 6"]
    end
    subgraph Merged["After merge"]
        M["{A:max(3,2), B:max(1,4)}<br/>= {A:3, B:4}, total = 7"]
    end
    A1 --> M
    A2 --> M

Cost of linearizability

Linearizability is expensive because it requires coordination. Three production approaches to paying that cost:

Google Spanner’s TrueTime: GPS receivers and atomic clocks in every datacenter bound clock uncertainty to a few milliseconds (epsilon)²⁰. Writes wait out the uncertainty interval (“commit wait,” roughly 2 x epsilon) before acknowledging, ensuring timestamps are globally ordered. This makes cross-continent linearizability feasible at ~7-14 ms commit overhead rather than full round-trip latency.

Raft ReadIndex: the leader confirms it is still leader by exchanging heartbeats with a majority before serving a read. etcd uses this for strict serializable reads²¹. Cost: one round trip to the majority on every strong read.

Lease reads: a leader holds a time-bounded lease. During the lease, it serves reads without coordination. If the lease expires (or the leader’s clock drifts), reads block until a new lease is acquired. CockroachDB uses lease-based reads with a default max clock offset of 500 ms¹⁵.

Real-World Example

Google Spanner: external consistency across continents.

Spanner is the first and most notable production system that provides external consistency (stronger than linearizability, extending to multi-row transactions) at global scale²²²⁰. Here is how it works:

Every Spanner datacenter has GPS receivers and atomic clocks. The TrueTime API returns a bounded interval [earliest, latest] with the true time guaranteed to be inside. Under normal operation, epsilon (the interval width) is a few milliseconds²⁰.

When a transaction commits, the coordinator assigns a commit timestamp and then waits until TT.now().earliest > commit_timestamp. This “commit wait” ensures that any transaction starting after the commit will get a higher timestamp, preserving real-time order across continents. The wait is roughly 2 x epsilon, typically under 14 ms²⁰.

sequenceDiagram
    participant C as Client
    participant Coord as Paxos Coordinator
    participant TT as TrueTime
    participant R as Replicas
    C->>Coord: COMMIT transaction T1
    Coord->>TT: TT.now() = [earliest, latest]
    Coord->>Coord: assign ts = latest
    Coord->>Coord: wait until TT.now().earliest > ts
    Note over Coord: ~7-14 ms commit wait
    Coord->>R: replicate via Paxos
    R-->>Coord: majority ACK
    Coord-->>C: COMMIT OK (ts)
    Note over C: Any T2 starting now gets ts2 > ts1

Read-only transactions use MVCC snapshot reads at a Paxos-ordered timestamp and do not block writes. Reads can also run with bounded staleness (served from any replica, cheaper) or strong (served from the Paxos leader)²².

The trade-off is clear: Spanner pays ~7-14 ms of commit latency on every write for the guarantee that the entire planet sees a single consistent timeline. This is worth it for Google AdWords billing and F1, where financial correctness across regions is non-negotiable. For a social feed or analytics pipeline, it would be overkill.

Trade-offs

Rows are ordered by consistency strength (strongest at the top, weakest at the bottom); every row is a real production choice backed by a named system (Spanner, Cosmos DB, MongoDB causal sessions, DynamoDB, Cosmos DB bounded staleness), and the “Our Pick” column answers the single decision “which model should this system use” rather than encoding a sequence.

Common Pitfalls

Exercise

Design Challenge: You are building a multiplayer trivia app. Players answer questions; the leaderboard shows scores. A question has a 10-second window, after which the correct answer and updated leaderboard flash simultaneously for all players. Players should see their own score update instantly when they answer, and see each other’s scores consistently during the reveal. Pick a consistency model for (a) the per-player score writes and (b) the reveal/leaderboard display.

Key Takeaways

• Consistency is a contract with readers, not writers. Ask “what is a reader allowed to see?” before picking a model.
• “Consistency” means three different things (ACID-C, CAP-C, replica consistency). Use the precise term: linearizable, serializable, causal, read-your-writes.
• Linearizability is simple to reason about but expensive and partition-fragile. Spanner pays ~7-14 ms commit wait per write for global linearizability²⁰.
• Causal consistency is the strongest model that remains totally available under partitions². It is the right default for human-facing multi-user applications.
• The four client-centric guarantees (RYW, monotonic reads, monotonic writes, writes-follow-reads) describe what a single user must never experience. Get these right and most “my UI is confused” bugs vanish.
• Snapshot isolation is not serializable. Oracle and Postgres “Repeatable Read” permit write skew¹².
• Almost every distributed database has shipped with a surprising consistency bug at its default configuration²³. Read the Jepsen report before trusting vendor claims.

Further Reading

• Designing Data-Intensive Applications, Ch. 5 and 9 (Kleppmann) - the canonical textbook treatment of replication, consistency models, and consensus; read before attempting any multi-region design.
• Linearizability: A Correctness Condition for Concurrent Objects (Herlihy and Wing, 1990) - the paper that formally defines linearizability; essential for understanding why real-time ordering matters.
• Please stop calling databases CP or AP (Kleppmann, 2015) - the essay that explains why CAP’s binary classification confuses more than it clarifies.
• Session Guarantees for Weakly Consistent Replicated Data (Terry et al., 1994) - the origin of RYW, monotonic reads, monotonic writes, and writes-follow-reads.
• Eventually Consistent (Vogels, ACM Queue 2008) - Amazon CTO’s classic framing of the eventual consistency trade-off and why different workloads deserve different guarantees.
• Jepsen consistency models reference - interactive map of every consistency model with arrows showing implication; the clearest single-page reference online.
• Azure Cosmos DB consistency levels - a rare commercial system that exposes five named levels with precise trade-off documentation.
• Spanner, TrueTime, and the CAP Theorem (Brewer, 2017) - Brewer’s own explanation of why Spanner appears to violate CAP and what “effectively CA” means in practice.
• A Comprehensive Study of CRDTs (Shapiro et al., INRIA 2011) - the definitive CRDT taxonomy; essential background for understanding conflict-free eventual consistency.
• CockroachDB’s consistency model (Matei, 2021) - precise description of serializable-but-not-strict-serializable and the “causal reverse” anomaly.

Flashcards

References