Consistency models and isolation guarantees

Why it matters

When data has several copies, or several clients act at once, "what will this read return?" has more than one defensible answer. Consistency models make the answer precise. Interviewers use them to check whether you can name the guarantee a feature needs (a user must see their own profile edit; two concurrent withdrawals must not overdraw an account) and what it costs. Vague phrases like "strongly consistent" are where many designs quietly break.

Core ideas

A model is a rule about which histories (invocations and responses as clients observe them) are allowed.

Linearizability (single objects): every operation appears to take effect atomically at an instant between its invocation and its response, and those instants respect real time. Once a write completes, every later read from any client sees it or something newer: the behavior of a single copy. It composes per object and is what leader election, locks and uniqueness checks need.

Sequential consistency keeps one total order consistent with each client's program order, but that order need not respect real time across clients. Causal consistency only requires that causally related operations (a reply and the post it answers) are seen in order by everyone; concurrent operations may appear in different orders. Causal consistency can stay available during a partition if clients keep talking to the same replica; linearizability cannot.

Session guarantees are cheap per-client promises that are often enough:

• Read-your-writes: a client sees its own completed writes. Route its reads to the leader for a while, or remember the log position of its last write and read only from replicas that have reached it.
• Monotonic reads: a client never sees time go backwards, for example by sticking to one replica.
• Consistent prefix: readers see writes in an order that respects causality, so an answer never appears before its question.

Eventual consistency only promises convergence once writes stop. It says nothing about what a read returns meanwhile, so it needs a convergence rule (last-writer-wins, merge functions, CRDTs) and usually some session guarantees.

Transactions are a different axis. Serializability: concurrent transactions produce the result of some serial order, with no real-time constraint, so a transaction that starts after another commits may still be ordered before it. Strict serializability adds real-time order; think of it as serializability plus linearizability. Snapshot isolation gives each transaction a consistent snapshot but permits write skew. Keep the "C" of ACID (application invariants) separate from all of these.

CAP, stated carefully. The proved result concerns a replicated read/write register: if the network can lose messages between nodes, you cannot guarantee both linearizability and that every request to a non-failed node eventually receives a response. It says nothing about latency, about systems that were never linearizable, or about normal operation. Most real databases are neither "C" nor "A" in these strict senses, so labeling a product CP or AP misleads. PACELC adds the everyday tradeoff: under a Partition choose Availability or Consistency; Else choose Latency or Consistency, because coordination costs round trips even on a healthy network.

Common misconceptions

• "Serializable means I always read the latest data." Serializability allows any serial order, including one that places a read-only transaction before a write that already committed. Real-time guarantees need strict serializability.
• "CAP means pick two of three." Partitions are not optional, and the theorem constrains behavior only during one. The real choice is per operation: wait or fail, versus answer with possibly stale data.
• "Eventual consistency means data is usually fresh." It bounds nothing; staleness can grow without limit under load or partition. Measure replication lag and add session guarantees where users would notice.
• "Quorum reads and writes give linearizability." Overlapping quorums are necessary, not sufficient; sloppy quorums, concurrent writes and partially failed writes still produce non-linearizable histories.
• "Linearizability and serializability are the same." One is about single-object operations in real time, the other about multi-object transactions in some serial order.

How to approach it

Learn the definitions from DDIA Ch. 9 and the Jepsen map, then practice on histories: draw two or three clients on a timeline and decide which read results each model allows. Map each model to a mechanism (single leader, synchronous replication, consensus, client-side tokens). Graduates should define linearizability and explain a stale-read anomaly. Mid-level candidates should choose guarantees per feature and implement read-your-writes. Senior candidates should argue the latency and availability cost of each choice and recognize when a weaker model plus compensation is the better product decision.