These are study notes I keep coming back to, cleaned up enough to be useful to someone else. The framing I find most helpful: a consistency model is a contract between a storage system and the people using it. It tells you which behaviours are allowed and, more importantly, which surprising ones are not.
The tension running through all of it is the usual one — stronger guarantees are easier to reason about and more expensive to provide. Latency, availability, and consistency are in a constant argument, and picking a model is mostly about deciding which one loses.
Linearizability
The strongest single-object model. Every operation appears to take effect instantaneously at some point between when it was invoked and when it returned, and once a write is acknowledged, every later read sees it. In effect, the system behaves as if there were a single copy of the data and one global clock.
It’s the easiest model to reason about and the most expensive to provide — it generally requires coordination on the critical path, which costs latency and, under partition, availability.
Sequential consistency
A step weaker. All operations appear in some total order, and each process’s operations appear in the order it issued them — but that global order need not match real time. Two observers will agree on the order of events; they just might both be looking at a slightly stale present.
The classic distinction: linearizability is sequential consistency plus the real-time ordering constraint.
Causal consistency
Weaker still, and often the sweet spot. Operations that are causally related — a write that a later write depends on — are seen by everyone in that order. Operations with no causal link can be observed in different orders by different processes.
This is enough to rule out the genuinely confusing anomalies (you never see a reply before the message it answers) while still allowing high availability. A lot of “feels consistent enough” systems are really targeting this.
Eventual consistency
The weakest commonly used guarantee: stop writing, wait, and all replicas converge to the same value. It says nothing about when, and nothing about what you read in the meantime.
It sounds flimsy, but for the right workload it’s exactly right — shopping carts, view counts, presence. The cost moves out of the storage layer and into application logic: you now own conflict resolution, and “last write wins” is a decision, not a default.
The actual takeaway
The instinct is to reach for the strongest model available. The discipline is to reach for the weakest one that still makes your application correct, because everything above that line is latency and availability you’re paying for and might not need. Half of distributed systems design is figuring out where that line is for the problem in front of you.
Reading list behind these notes: Kleppmann’s Designing Data-Intensive Applications for the synthesis, and the original linearizability and CAP papers for the formal grounding.