Consistency Models | System Design Interview Handbook

⚖️

The CAP Theorem

C vs A, only during a partition

CAP names three properties a distributed store might want: Consistency (every read sees the most recent write, as if there were one copy), Availability (every request gets a non-error response), and Partition tolerance (the system keeps working when the network drops messages between nodes).

The popular framing, "pick two of three," is wrong. Partitions are not a choice you make; networks fail whether you like it or not. So P is not optional for any real distributed system. The theorem is really about one moment: when a partition happens, do you sacrifice consistency or availability?

   Client writes x=2                                   Client reads x
          │                                                   │
          ▼                                                   ▼
   ┌───────────────┐        ╳  partition  ╳         ┌───────────────┐
   │    Node A     │ ┈┈┈┈┈┈┈┈┈┈┈ X ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ │    Node B     │
   │  accepts x=2  │          (cannot sync)          │  still x = 1  │
   └───────────────┘                                 └───────────────┘

   CP choice → Node B refuses the read (or A refuses the write): no stale data, but unavailable.
   AP choice → Node B returns x=1: available, but the read is stale until the partition heals.

CP — consistency over availability Refuse rather than lie

During a partition, reject requests the system can't serve correctly. The minority side stops taking writes; some clients get errors.

Fits: anything where a wrong answer is worse than no answer — balances, inventory, locks, config, leader election.

Examples: ZooKeeper, etcd, HBase, Spanner.

AP — availability over consistency Answer, reconcile later

During a partition, keep serving from whatever node you can reach. Reads may be stale, writes may conflict, and the system reconciles once the partition heals.

Fits: anything where a slightly stale answer is fine — feeds, likes, product catalogs, view counts.

Examples: Cassandra, DynamoDB, Riak.

⚠️

Two traps. First, "CA" systems don't exist in the distributed sense — drop P and you just have a single node. Second, CAP's C means linearizability, not the C in ACID; they're unrelated letters that happen to share a word.

🔀

PACELC: The Part CAP Leaves Out

the trade exists even without partitions

CAP only speaks about the partition case, which is rare. PACELC finishes the sentence: if there is a Partition, choose Availability or Consistency; Else, in normal operation, choose Latency or Consistency.

That "else" is the honest part. Any system that replicates data faces a choice on every write: wait for replicas to acknowledge before returning (consistent, slower) or return as soon as one node has it (fast, possibly stale). You pay this tax all day, not just during the once-a-quarter partition.

Reading the four-letter labels Classification

System	PACELC	Meaning
Cassandra, Dynamo	PA / EL	Stay available in a partition; favor latency otherwise. Tunable, but this is the default posture.
Spanner	PC / EC	Consistency always, even at the cost of latency. Pays with synchronized-clock waits.
Single-node RDBMS	— / EC	No partition story; strongly consistent because there's one copy.
MongoDB (default)	PA / EC	Available under partition; consistent reads from the primary in normal operation.

💡

PACELC is the more useful lens in an interview because it forces you to talk about the common case. Saying "in normal operation I'll trade a little latency for read-your-writes here, but go EL for the like counter" shows you understand the cost is continuous, not a partition-only event (Tradeoffs).

📶

The Consistency Spectrum

linearizable → eventual

"Consistent" is not one thing. It's a ladder, and each rung down buys lower latency and higher availability by allowing one more kind of anomaly. Know the rungs and one concrete anomaly each, because that anomaly is how you explain the level to an interviewer.

  STRONGER ◀───────────────────────────────────────────────────────▶ WEAKER
  more coordination · higher latency          less coordination · lower latency

   Linearizable  ──▶  Sequential  ──▶   Causal    ──▶   Eventual
   single-copy        global order       cause-before      replicas
   illusion,          but no real-time    -effect only,     converge if
   no stale reads     ordering            concurrent free   writes stop

Each rung and the anomaly it does or doesn't allow One example each

Level	Guarantee	Anomaly at this level
Linearizable	Every read returns the latest write; the system acts like one copy on a single timeline.	None. This is the gold standard, and the most expensive.
Sequential	All nodes agree on one order of operations, respecting each client's own order.	Two users may disagree on real-time timing: your write "happened first" on the clock but is ordered after mine.
Causal	Operations that are causally related are seen in order everywhere; unrelated ones may differ.	Concurrent writes can appear in different orders on different replicas — but you never see a reply before the comment it answers.
Eventual	If writes stop, all replicas converge to the same value. That's the only promise.	Read-your-writes violation: you post a comment, refresh, and it's gone because you hit a lagging replica.

ℹ️

The gap between linearizable and everything else is the one that matters most in practice. Linearizability needs coordination on the write path — a consensus round or a single leader (Consensus) — which is exactly the latency PACELC warned about. Everything below it trades that coordination away.

🎫

Session Guarantees

cheap consistency where users notice

Full linearizability is often overkill. What users actually notice is inconsistency within their own session: they post something and it vanishes, or a page refresh shows older data than the last one. Session guarantees fix exactly those, and they're cheap because they only constrain one client's view, not the whole cluster.

The four that carry most products Per-session

Guarantee	Promise	Bug it prevents
Read-your-writes	You always see your own updates.	Comment disappears right after you post it.
Monotonic reads	Once you've seen a value, you won't later see an older one.	Timeline jumps backward on refresh.
Monotonic writes	Your writes apply in the order you issued them.	Second edit lost behind the first.
Writes-follow-reads	A write you make is ordered after the read it was based on.	Reply appears before the post it answers.

💡

These are usually implemented by pinning a session to one replica (sticky routing) or by tracking the version a client has seen and refusing to serve older ones. On an eventually-consistent store, layering read-your-writes on top is often all a social product needs. Reach for that before you reach for global strong consistency (Replication).

🧪

ACID vs BASE

two philosophies, one spectrum

ACID Transactional

Atomicity — all of a transaction happens, or none of it.
Consistency — a transaction moves the DB from one valid state to another, preserving invariants.
Isolation — concurrent transactions don't see each other's partial work.
Durability — once committed, it survives a crash.

Cheap and natural on a single node. The classic home of relational databases.

BASE Available

Basically Available — the system answers, even if degraded.
Soft state — data may change without input as replicas sync.
Eventual consistency — replicas converge over time.

The design philosophy of AP systems: give up strict guarantees to stay up and stay fast at scale.

⚠️

ACID within one node is easy; stretching it across nodes is where the cost hides. Multi-record, multi-service atomicity needs two-phase commit or sagas, and that machinery is a whole topic of its own (Distributed Transactions). And again: ACID's "C" (invariants) is not CAP's "C" (linearizability).

🎯

Choosing in an Interview

map the requirement to the model

The move is not to pick one consistency level for the whole system. It's to look at each piece of data and ask what a wrong or stale answer costs. Most real designs mix levels: strong where money and identity live, eventual for the derived views that dominate traffic.

Product requirement → model Mapping

Requirement	Model	Why
Payments, balances, inventory, seats	Strong / linearizable	Double-spend or overselling is unacceptable; correctness beats latency.
Usernames, locks, leader election	Strong / linearizable	"Exactly one" must be true across the cluster.
Comment threads, collaborative editing	Causal	Cause-and-effect order must hold; concurrent edits can be reconciled.
Your own posts and profile edits	Session (read-your-writes)	Users must see their own actions; others can lag briefly.
Feeds, likes, view counts, catalogs	Eventual	Read-heavy, tolerant of staleness; availability and latency win.

💡

When the interviewer asks "how consistent does this need to be?", the strong answer is never "strongly consistent everywhere." It's "the order-of-record is strongly consistent; the timeline and counters are eventual with read-your-writes for the author." Naming the split is the senior signal (Design Process).

📋

Quick Reference

models on one card

Model	Guarantee	Example system	Anomaly avoided
Linearizable	Reads see the latest write, single-copy illusion	etcd, ZooKeeper, Spanner	Stale reads, lost order
Sequential	One global order respecting per-client order	Distributed logs	Reordered per-client ops
Causal	Cause precedes effect everywhere	MongoDB causal sessions	Reply before its comment
Read-your-writes	You see your own updates	Session layer on eventual store	Your write vanishing
Eventual	Replicas converge if writes stop	Cassandra, DynamoDB, DNS	Only guarantees convergence

ℹ️

The one-liners to keep ready. CAP: partitions force a choice between consistency and availability. PACELC: even without partitions, replication trades latency against consistency. The move: match each piece of data to the weakest model that still hides the anomaly users would notice.