Consistency Models

A consistency model is a contract about what a read may return given the writes that happened before it. Stronger models are easier to program against and more expensive to provide.

Linearizability

Every operation appears to take effect instantaneously at some point between its start and its completion, and all clients observe the same order. Once a write completes, every subsequent read by any client sees it.

This is the model that makes a distributed system feel like a single machine. It requires coordination — consensus for writes, and reads that either go through the leader or confirm leadership. CockroachDB, YugabyteDB and etcd provide it. A quorum read/write configuration in Cassandra does not, because concurrent operations can still be ordered inconsistently.

Sequential consistency

All clients observe operations in the same order, but that order need not match real time. A write may become visible to everyone a little later than it completed, as long as nobody sees a contradictory order.

Causal consistency

Operations that are causally related are seen in the same order by everyone; concurrent operations may be seen in different orders. If a comment references a post, no client sees the comment before the post.

This is often the sweet spot for distributed applications: it prevents the anomalies users actually notice, without global coordination. MongoDB provides causal consistency within a session through cluster time and operation time tokens.

Session guarantees

These are per-client promises, and they are usually what an application really needs:

• Read-your-writes — a client sees its own writes. Violated by the classic bug: write to the primary, immediately read from a replica, and show the user stale data.
• Monotonic reads — a client never sees time go backwards. Violated when a client is routed to a lagging replica after reading from a fresh one.
• Monotonic writes — a client's writes apply in the order it issued them.

Eventual consistency

Given no new writes, replicas eventually converge. It says nothing about how long "eventually" is, or what a client sees meanwhile — including reads that go backwards in time.

Eventual consistency is a legitimate choice for data where staleness is harmless: view counters, recommendation inputs, dashboards. It is a poor choice where a stale read triggers an action, such as checking a balance before allowing a withdrawal.

Choosing per operation

Most engines that offer weak consistency also let you strengthen it per query, and paying only where it matters is the point: