Consistency Models

A consistency model is a contract about which histories the system is allowed to produce — that is, which observations you will never make. "Strong consistency" names no such contract, and the first skill this module teaches is refusing the phrase until someone says which model they mean.

Q · Someone says the database is "strongly consistent". What have they actually told me?

The strongest single-object guarantee: the system behaves as if every operation took effect instantaneously at some moment between its invocation and its response, and that moment respects real time. The whole subtlety lives in the word "interval" — an operation is a span, and linearizability asks whether some placement of effect points inside those spans explains what you saw.

Q · What does it mean for a distributed system to behave "as if there were only one copy"?

These are confused constantly, including in vendor documentation. Serializability is about transactions being equivalent to some serial order. Linearizability is about single operations respecting real time. Neither implies the other, and the conjunction has its own name — strict serializability — which is what most people mean when they say either word.

Q · My database says it is serializable. Does that mean a read always sees the latest committed write?

The most maligned and most misdescribed model in the field. Its actual claim is narrow and precise: if no new updates are made to an item, all replicas eventually agree on its value. It is a liveness property with no safety content, which means it forbids nothing you can observe in a finite run — and that, rather than "stale data", is the honest criticism.

Q · What exactly is an eventually consistent system promising me?

Preserve the order of operations that are causally related; allow any order for operations that are genuinely concurrent. It removes the anomalies that make users think a system is broken, it remains available during a partition, and there is a theorem saying nothing stronger can do both.

Q · How much ordering can I keep while still accepting writes on both sides of a partition?

Four properties — read your writes, monotonic reads, monotonic writes, writes follow reads — scoped to a single session. They cost a small amount of client-carried state, they require no agreement between nodes, and together they eliminate nearly every consistency complaint a user actually files.

Q · What is the cheapest set of guarantees that makes a replicated system stop feeling broken to its users?

Not "pick any two of consistency, availability and partition tolerance" — that framing is wrong and has misled a generation of design discussions. The theorem says that during a network partition, a system cannot be both linearizable and available for every request at every non-failing node. Partitions are not a choice you make; they happen to you.

Q · What does CAP actually constrain, and why is "pick two" the wrong way to say it?

CAP describes one failure. PACELC adds the case you actually live in: if there is a Partition, trade Availability against Consistency — Else, trade Latency against Consistency. The second half is where nearly all your engineering time goes, and CAP is silent about it.

Q · The network is fine, which is almost always. What is the trade-off then?

The decision is not made by comparing models. It is made by naming the invariant that must not be violated, checking whether one node can verify it alone, and then buying the weakest guarantee that protects it — per operation, not per system.

Q · I have to pick a consistency level for this operation. How do I decide without guessing?