Consistency Models

One-liner: A consistency model is the contract about which writes a read may observe; stronger models cost latency and availability.

Say this#

SAY THIS

Linearizable (strong) — every op appears instantaneous at a single point between invocation and response; reads see latest write. The gold standard.
Sequential — all nodes see ops in the same order, consistent with each client's program order, but not necessarily real-time order.
Causal — causally related writes are seen in order; concurrent writes may be seen in any order.
Eventual — given no new writes, all replicas converge. No ordering guarantee.
Read-your-writes (read-after-write) — a client always sees its own writes.
Monotonic reads — a client never sees time go backwards (no older value after a newer one).
Monotonic writes — a client's writes are applied in order.
Quorum (N, R, W) — N replicas, read from R, write to W; R + W > N gives overlap.
Sloppy quorum / hinted handoff — accept writes on substitute nodes during failure; weakens guarantee.
Vector clock / version vector — track causality to detect concurrent writes.
Serializability vs linearizability — serializability is about transactions (isolation), linearizability about single-object recency; "strict serializability" is both.

How it works#

TEXT

strong (linearizable)   ^  sequential   |  causal   |  session guarantees: read-your-writes, monotonic reads/writes   v  eventualstrong (linearizable)
   ^  sequential
   |  causal
   |  session guarantees: read-your-writes, monotonic reads/writes
   v  eventual

Quorum reads/writes (Dynamo, Cassandra, Riak):

Write to N replicas, wait for W acks.
Read from R replicas, return the newest version (by timestamp/vector clock).
If R + W > N, at least one read replica has the latest write → strong-ish (not linearizable under failure/sloppy quorum).
Common settings: N=3, W=2, R=2 (balanced); W=3,R=1 (read-heavy); W=1,R=3 (write-heavy).

Session guarantees in practice: route a user's reads to the leader for N seconds after their write, or carry a version/LSN token the replica must have caught up to.

Trade-offs#

Choice	Pro	Con
Linearizable	Simple reasoning; safe for locks, uniqueness, balances	Needs consensus or single leader; cross-region latency; unavailable in minority partition
Causal	Preserves "reply after post" ordering, available under partition	Metadata (vector clocks) overhead; rarely offered natively (MongoDB causal sessions, Cosmos)
Eventual	Lowest latency, highest availability	Stale reads, lost-update risk without conflict resolution
Read-your-writes	Cheap fix for the most visible anomaly	Requires sticky routing or version tokens
R+W>N quorum	Tunable per request	Latency = slowest of W/R nodes; not truly linearizable

Numbers#

N=3, R=2, W=2 is the canonical Dynamo-style default.
DynamoDB: eventually consistent read costs half a strongly consistent read (0.5 vs 1 RCU per 4 KB).
Typical async replication lag: milliseconds in-region, hundreds of ms to seconds cross-region or under load.

Say this#

How it works#

Trade-offs#

Numbers#

In the interview#