Consistency Models — System Design

Summary#

A consistency model is a contract between a storage system and its clients about which orderings of reads and writes are observable. The strongest models give you the illusion of a single, instantaneously-updated copy; the weakest let any two readers see contradictory state for a while. Stronger models cost more latency, throughput, and availability — sometimes a lot more.

Why it matters#

“Strong consistency” is the lazy default in interview answers and the most expensive choice in production. Every cross-region database call, every quorum write, every two-phase commit — that’s the bill for picking the strong end of the spectrum.

The senior signal is choosing the weakest model your invariants tolerate. A “likes count” is fine with eventual consistency. A bank account balance is not. The middle of the spectrum — read-your-writes, monotonic reads, causal — is where most real systems actually live, and interviewers love it because it exposes who’s actually thought about the trade-offs versus who’s reciting CAP.

How it works#

Walk the ladder from strongest to weakest. Each step gives up one ordering guarantee and buys back availability or latency.

Linearizability (strict / external)#

Every operation appears to take effect atomically at some point between its invocation and its response. Reads always return the most recent committed write. Implementation: single-leader synchronous replication, consensus (Raft, Paxos), or single-node. Cost: coordination on every write; cross-region writes pay the wide-area RTT every time. Examples: etcd, ZooKeeper, Spanner, CockroachDB serializable.

Sequential consistency#

All operations appear in some single global order that respects each client’s program order — but not necessarily real-time order. A read may return a slightly stale value as long as no two clients disagree on the order. Rarely chosen explicitly; mostly a theoretical waypoint.

Causal consistency#

Operations that are causally related (write B happened-after read A) are seen in the same order by all observers. Concurrent operations may be observed in any order. Implementation: vector clocks or hybrid logical clocks. Cost: metadata overhead per write; no global coordination. Examples: COPS, MongoDB causal sessions, Dynamo-style with vector clocks.

Read-your-writes (a session guarantee)#

A client always sees its own writes on subsequent reads, but other clients may not. Implementation: pin the client to a replica with its writes, or stamp reads with a “min version” token. Cost: session affinity, a small token in the request. The pragmatic default for user-facing apps.

Monotonic reads#

A given client never sees state go backwards in time. Once you read version 7, you won’t see version 5 on a later read. Implementation: same session-pinning trick. Often coupled with read-your-writes.

Eventual consistency#

If no new writes occur, all replicas converge eventually. No bound on “eventually”. Implementation: async replication, anti-entropy gossip, last-write-wins with timestamps. Cost: none on the write path; clients must tolerate stale and out-of-order reads. Examples: Cassandra default, DynamoDB eventually-consistent reads, DNS.

Variants and trade-offs#

Strong (linearizable) — simplest reasoning, hardest implementation. Coordination on every write. Cross-region writes pay 100–200 ms. Availability drops during partitions (you must pick CP). Use for: leader election, locks, balance / inventory invariants, exactly-once intent.

Eventual — best throughput and availability, hardest reasoning. Application code must handle stale reads, conflicts, anti-entropy. Use for: counters, feeds, analytics, derived state, anything that converges to “approximately right”.

PACELC is the framing to know: in the presence of a network Partition you trade Availability for Consistency; Else (no partition) you trade Latency for consistency. Most production systems live in the “E” half — they’re not actively partitioned, but every consistency level still costs latency.

Read-your-writes + monotonic reads gives you ~95% of the felt experience of strong consistency at ~5% of the cost. Most “we need strong consistency” requirements are actually this in disguise.

Why CRDTs are not a free strong-consistency upgrade

Conflict-free Replicated Data Types let you merge concurrent updates without a coordinator — but only for operations whose merge is mathematically commutative (sets, counters, certain text types). They give eventual consistency with no conflict resolution code, not strong consistency. A CRDT counter is great for likes; it cannot enforce “never go negative”.

When this is asked in interviews#

Always, in two specific moments:

NFR clarification (Step 1). “What consistency do reads need?” If the candidate says “strong” without thinking, the interviewer drills: “for the timeline? for the like count? for the username uniqueness check?” The right answer is usually three different levels in one system.
Data layer drill-down (Step 6). “How does this handle a network partition between the two regions?” The expectation is to name CAP or PACELC, then describe the concrete degradation — read-only mode, last-known-good cache, region-pinned writes.

Senior, staff, and infrastructure roles weight this heavily. Database companies (Snowflake, Mongo, Cockroach, Neon, PlanetScale), payments (Stripe, Adyen), and any “exactly-once” system (Kafka users, billing) will spend half the interview here.

Common follow-ups:

“Walk me through what a stale read looks like to the user in your design.”
“Where would you put a CRDT and where would you refuse to?”
“What’s the difference between read-your-writes and full strong consistency, and which does your design actually need?”