What it is
A consistency model is the contract between a replicated store and its clients: which reads are allowed to return which writes. Stronger models make a distributed system behave more like a single machine; weaker models admit anomalies in exchange for latency and availability.
When you care
The consistency question hides inside every replication answer, and interviewers ask it concretely: “A user writes, then immediately reads — what do they see?” The trap is treating consistency as binary (“strong vs eventual”) — the useful answers live in between, and the strongest senior signal is matching the model to the data: a checkout needs more than a like counter.
The models
From strongest to weakest:
| Model | Promise | Typical cost |
|---|---|---|
| Linearizable (“strong”) | Every read sees the latest acknowledged write; all clients agree on one order | Consensus or single-leader reads; cross-replica coordination on every operation |
| Sequential | All clients see the same order, but it may lag real time | Cheaper than linearizable; still global coordination |
| Causal | Effects never appear before causes (an answer never precedes its question) | Per-item version metadata; no global order needed |
| Session guarantees | Read-your-writes, monotonic reads — promises scoped to one client | Session pinning or leader-routing; cheap |
| Eventual | Replicas converge if writes stop; reads may see anything meanwhile | Nearly free — and nearly promise-free |
Linearizable is what people mean by “strong”: the system behaves as if one copy exists. You need it where an agreed-upon now matters — locks, leader election, unique-name claims, inventory decrements. It’s the only model on this list that requires coordination on the critical path, which is why everything else exists.
Causal is the strongest model that survives a network partition (no global agreement needed — just “carry your causes with you”). It eliminates the anomalies humans actually notice (replies before questions) at a fraction of linearizability’s cost.
Session guarantees are the workhorse. Users don’t compare notes across accounts; they notice their own writes vanishing. Read-your-writes + monotonic reads, scoped per user, fix the visible problems and let the global system stay eventual.
Eventual is the honest name for “async replication with no read routing.” It’s the right model for data where any recent-ish value is fine: counters, presence, analytics, caches.
CAP and PACELC, in one paragraph each
CAP: during a network Partition, choose Consistency (refuse some requests) or Availability (serve everyone, possibly stale/conflicting). It’s a statement about a failure moment, not a database personality type — and “CA” isn’t an option, because partitions aren’t.
PACELC adds the part CAP misses: Else — when there is no partition — you still choose between Latency and Consistency, because consistent operations pay coordination round-trips on every request, not just during failures. This is the everyday tradeoff; partitions are the rare one.
Matching model to data
| Data | Model to ask for | Why |
|---|---|---|
| Locks, leader election, unique usernames | Linearizable | Two holders/owners/claimants is a correctness failure |
| Orders, payments, inventory | Linearizable (or single-writer per key) | Money; oversell is unrecoverable in product terms |
| Social content (posts, comments) | Causal + read-your-writes | Users must see their own writes and sane ordering; global order is invisible |
| Feeds, timelines | Eventual with session guarantees | Staleness in seconds is the product’s stated tolerance |
| Counters, likes, metrics | Eventual | Approximate is fine; convergence is enough |
When to pick what
- Default claim in an interview: per-data-type — linearizable for the small coordination core, session-guaranteed eventual for the bulk.
- Asked “strong or eventual?”: reject the binary; name causal and session guarantees as the practical middle.
- AP system (Dynamo-style): eventual + quorum tuning;
R+W>Nshrinks staleness but does not buy linearizability. - Need linearizable in an AP store: you don’t — move that data to a consensus-backed store (etcd, ZooKeeper, Spanner-class SQL).
Related
- Reference: Replication Strategies — the topologies whose lag and conflicts these models describe.
- Walkthrough: Designing a Distributed Key-Value Store — quorum arithmetic and an honest account of what R+W>N does and doesn’t guarantee.
- Reference: Distributed Transaction Patterns — atomicity across keys, the dimension consistency models don’t cover.