Consistency Models

Linearizable, causal, session guarantees and eventual consistency — and which feature needs which.

"Is it consistent?" isn't a yes/no question. A consistency model is a contract that says which values a read is allowed to return when data is replicated. Stronger models are easier to reason about; weaker models are faster and more available. Naming the precise guarantee a feature needs — rather than just "strong" or "eventual" — is one of the clearest signals of senior-level thinking. For the trade-off with availability, see CAP Theorem.

The spectrum

Linearizability

Every operation appears to take effect at a single instant between its start and end, and all clients agree on that order.
Needed for uniqueness and correctness constraints: "only one person gets this seat," "this username is taken," "only one leader," "balance can't go negative."
Cost: coordination on every write (a leader or quorum), so higher latency, and unavailability on the minority side of a network partition.

Causal consistency

Preserves cause and effect: a reply never appears before the message it answers; a comment never appears on a post you can't see yet.
Can be provided without global coordination, so it remains available during partitions — the strongest model that can.
Implemented by tracking dependencies with version vectors or logical timestamps. See Clocks & Ordering.

Session guarantees

Often all a user-facing feature actually needs:

Read-your-writes — after I post, I see my post.
Monotonic reads — I never see newer data and then older data.
Monotonic writes — my writes are applied in the order I made them.
Writes-follow-reads — if I reply after reading a post, the reply is ordered after that post.

Typical implementations: route a user to the same replica, read from the leader shortly after a write, or have the client carry the version/log position of its last write and have replicas wait until they've caught up.

Eventual consistency

Replicas accept reads and writes independently and converge later. Highest availability and lowest latency.
"Eventually" is usually milliseconds to seconds, but there is no bound during failures.
Concurrent writes must be reconciled: last-writer-wins (simple, may silently drop writes), application merge logic, or CRDTs.

Tunable consistency

Many stores let you choose per request:

Cassandra — ONE, QUORUM, ALL, LOCAL_QUORUM. Quorum reads plus quorum writes give strong reads for single keys.
DynamoDB — eventually consistent reads by default, strongly consistent reads at twice the cost.
MongoDB — read and write concerns, plus causally consistent sessions.

Choosing per feature

[!INTERVIEW] Name the guarantee "Inventory decrements need linearizability, so they're conditional updates against the primary. Product pages can be eventually consistent and served from cache. For reviews, users need read-your-writes, so after posting we show their review from the response and read it from the primary for the next minute."