Consistency & CAP

CAP says that when a network partition occurs, a distributed system must choose between consistency and availability. The framing is widely misused: CAP only applies during a partition. Absent one, you can have both, and the real everyday tradeoff is consistency versus latency — which is what PACELC adds.

The useful ladder, from strongest down:

Linearizable (strong): every read returns the most recent write, as if there were one copy. Expensive; requires coordination. Sequential: all nodes see operations in the same order, not necessarily real-time order. Causal: operations that are causally related appear in order everywhere; unrelated ones may not. Enough for most collaborative applications. Read-your-writes: you always see your own writes. Others may lag. Eventual: given no new writes, replicas converge. Says nothing about when.

Session guarantees are the practical middle of that ladder, and the ones a user would actually notice missing: monotonic reads (time never runs backwards, so a value that was there does not disappear on the next read), read-your-writes (your own change is always visible to you), and consistent prefix reads (you never see an effect before its cause — a reply before the message it answers). Each is cheap, usually bought by pinning a session to one replica or having the client carry the version it last saw, and together they cover most of what strong consistency is reached for.

Isolation is a different axis. The C in ACID is not the C in CAP. Isolation levels describe how concurrent transactions on one database are allowed to interleave; consistency models describe what a read on one replica may say about a write accepted by another. They are orthogonal, which is why a serializable database still hands you a stale read from a follower — and why "we use a strongly consistent database" settles less than the people saying it usually think.

Choose per operation, not per system. A payment must be linearizable. The like count on a post can be eventual and nobody will ever notice. Teams that pick one consistency level for an entire system either overpay everywhere or underpay somewhere that matters.

Quorums give tunable consistency: with N replicas, W + R > N guarantees a read overlaps the latest write. W=N, R=1 favours fast reads; W=1, R=N favours fast writes.

The question worth carrying into a design review is not which consistency model the system has. It is which one each operation needs, and what a user would actually notice if that operation were served one level weaker.