Consistency Models

“Consistency” is the most overloaded word in distributed systems. It means one thing in CAP (linearizability), another in ACID transactions (integrity constraints), and yet another in casual conversation (“the data is consistent”). This page is about the first kind: a consistency model is a contract between the storage system and the programmer about what a read is allowed to return. It is not a single setting but a spectrum, and choosing a point on it is one of the most consequential decisions in any distributed design.

The governing intuition: a stronger model is easier to reason about — fewer surprising interleavings, fewer “how did it return that?” bugs — but it forces more coordination, which means more latency and less availability (exactly the PACELC trade). Weaker models are fast and survive partitions, but they hand the surprises back to you. This page is a tour from strongest to weakest.

The spectrum, top to bottom

STRONGER  ┌────────────────────────────────────────────┐  easier to reason about
   ▲      │ Linearizable  (one copy, real-time order)   │  slower, less available
   │      ├────────────────────────────────────────────┤
   │      │ Sequential    (one global order, not real-  │
   │      │                time)                        │
   │      ├────────────────────────────────────────────┤
   │      │ Causal        (cause precedes effect)       │
   │      ├────────────────────────────────────────────┤
   │      │ Eventual      (converges... eventually)     │
   ▼      └────────────────────────────────────────────┘  faster, more available
WEAKER                                                     harder to reason about

Linearizable (strong) consistency

The gold standard. The system behaves as if there were a single copy of the data, and every operation takes effect at some instant between when it was invoked and when it returned. The practical consequence is the powerful one: once a write completes, every subsequent read — from any client, anywhere — sees it. There is a single, real-time-respecting timeline.

This is what makes a distributed counter, a lock, or a leader-election result trustworthy. It’s also what CAP’s “C” means. The cost: every operation must coordinate (typically a quorum write plus a way to read the latest), so latency rises and availability falls during partitions. Spanner, etcd, and ZooKeeper give you this for the data that needs it.

Sequential consistency

Subtly weaker. All operations appear in some single global order that all clients agree on, and each client’s own operations appear in the order it issued them — but that global order need not match real time. If Alice writes at 12:00:00 and Bob writes at 12:00:01, a sequentially consistent system may legally order Bob’s write before Alice’s, as long as everyone sees that same ordering. Linearizability adds the real-time constraint that sequential consistency drops. In practice few systems target sequential consistency directly, but it’s the conceptual rung between “respects the clock” and “respects causality.”

Causal consistency

Now we drop the global order entirely and keep only what truly matters for correctness in many apps: operations that are causally related are seen by everyone in the same order; concurrent operations may be seen in different orders. “Causally related” means one could have influenced the other — you read a message, then reply to it; everyone must see your reply after the message. But two unrelated posts by strangers can appear in either order on different replicas, and that’s fine.

Causal consistency is the sweet spot for a lot of collaborative software because it forbids the nonsensical orderings (an answer before its question) while permitting the harmless ones, and it can be maintained without global coordination — it’s achievable in an AP system. The machinery that tracks “what causally precedes what” is the subject of Time, Clocks & Ordering.

Eventual consistency

The weakest commonly named model: if writes stop, all replicas eventually converge to the same value. That’s the entire promise. It says nothing about what you read in the meantime — you may read stale data, you may read your own write and then not see it on the next read, you may see two writes in different orders. Convergence requires conflict resolution (last-write-wins, or merge logic like CRDTs — see Vector Clocks & CRDTs).

Eventual consistency is what powers DNS, shopping carts, and “likes” counters — places where being briefly wrong is cheaper than being slow or unavailable. The trap is its name: “eventual” can be milliseconds or, under a partition, much longer, and “eventually” gives the programmer no help during the window when things disagree.

Session guarantees: the practical middle

Pure eventual consistency is often too surprising for users, but full linearizability is too expensive. So real systems offer session (client-centric) guarantees — promises scoped to a single client’s view, which are cheap to provide and eliminate the most jarring anomalies:

• Read-your-writes — after you write, you always see at least that write. Without it, you post a comment, refresh, and it’s gone — the single most common “the site is broken” complaint.
• Monotonic reads — once you’ve seen a value, you never see an older one. Without it, refreshing a page can scroll time backward as your requests hit different replicas.
• Monotonic writes — your own writes are applied in the order you issued them.
• Writes-follow-reads — if you read a value and then write, your write lands after the value you read (causality, scoped to your session).

Read-your-writes, illustrated:

  You POST "hello"  ──►  replica A (has it)
  You GET  later    ──►  replica B (doesn't have it yet)   ← BAD: your post "vanished"

  With read-your-writes, the system routes/waits so YOU always
  see your own "hello", even while other users might not yet.

Most “consistency bugs” are missing session guarantees

Teams reach for full linearizability to fix a “my edit disappeared” report when read-your-writes (often implemented by pinning a client to a replica, or reading from the leader for a short window after a write) fixes it at a fraction of the cost. Match the guarantee to the anomaly the user actually notices, not to the strongest model you can name.

Choosing a point on the spectrum

The decision is always the same shape — what does this buy us, and what does it cost? Stronger consistency buys simpler application code: you reason as if there’s one copy, and whole classes of bugs cannot occur. It costs latency and availability, because correctness now requires coordination that a partition can block (CAP is unavoidable once you demand linearizability). Weaker consistency buys speed and uptime and survives partitions gracefully, but it pushes the hard cases — conflict resolution, surprising reads — up into your application. The skill is not picking the strongest model; it’s picking the weakest model that still hides every anomaly your users would call a bug. For the mechanics of how replicas actually diverge and reconcile, continue to Replication.

Check your understanding

1. Linearizability and sequential consistency both provide a single global order. What does linearizability add that sequential consistency drops?
2. Under causal consistency, why is it acceptable for two strangers’ unrelated posts to appear in different orders on different replicas, but not for a reply to appear before the message it answers?
3. What exactly does eventual consistency promise — and, just as importantly, what does it not promise about reads before convergence?
4. A user posts a comment, refreshes, and it’s gone. Which session guarantee is missing, and why is it usually cheaper to add than full linearizability?
5. Frame the consistency-strength decision as a “buys us / costs us” trade-off, and state the rule of thumb for choosing a level.