Consistency, Causality, Ordering, and Linearizability
Consistency models define what reads are allowed to see. The strongest models simplify reasoning by making distributed state look single-copy, but they charge latency and availability.
Consistency is not whether data is good or bad. It is the contract between write history and read observations.
The consistency ladder
Eventual consistency says replicas converge if writes stop, but reads may see stale values. Read-your-writes says a client sees its own updates. Monotonic reads say once a client has seen a value, it will not later see an older one. Consistent prefix says readers see writes in an order that preserves causality.
These client-centric guarantees are often enough and cheaper than global single-copy semantics. A user profile page may need read-your-writes after edit. A timeline may need consistent prefix so replies do not appear before parent posts. A metrics dashboard may tolerate eventual consistency.
Linearizability is stronger: operations appear to take effect atomically at a point between call and return, as if there were one copy. It is easy to understand and expensive across networks.
Causality and ordering
Causality asks what happened before what. If event B was produced after reading event A, then B causally depends on A. Causal ordering can be captured with sequence numbers, Lamport timestamps, version vectors, or dependency tracking.
Causality is weaker than total order. Two events can be concurrent: neither happened before the other. This is a feature, not a bug. It lets distributed systems avoid unnecessary coordination when operations do not conflict.
But some invariants require total order or agreement. Username uniqueness is the classic example: if two nodes concurrently register the same name, somebody must decide one winner. Causality alone cannot choose because the operations are concurrent.
The cost of linearizability
Linearizability usually requires coordination with a leader, quorum, or consensus group. That means network round trips on the critical path and reduced availability during partitions. In a multi-region system, the speed of light becomes part of the write latency.
The design discipline is to use linearizability surgically. Account balances, uniqueness constraints, lock acquisition, leader election, and model promotion state may need it. Feed counters, analytics, search indexes, cached recommendations, and many feature aggregates often do not.
Per-operation consistency is the senior move: one system can expose strong reads for critical control paths and eventual reads for cheap derived views.
Trade-offs
| Choice | Buys | Costs |
|---|---|---|
| Eventual consistency | Low latency, high availability, easy replication | Stale reads and application-visible anomalies |
| Causal consistency | Preserves dependencies without total coordination | Cannot enforce global uniqueness or single winner |
| Linearizability | Simple single-copy mental model | Coordination latency and lower partition availability |
| Per-operation consistency | Spends coordination only where needed | API and reasoning become more nuanced |
You should be able to name the contract this mechanism offers, the workload or invariant that justifies it, and the bill it sends somewhere else: read latency, write latency, storage, availability, freshness, or operational complexity.
If a system does not state its consistency model, users discover it by accident: stale permissions, duplicate names, missing writes, or dashboards that move backward.
Design prompts
- Which operations in a model registry require linearizability?
- Give an example where read-your-writes is enough but linearizability is overkill.
- Why can causal ordering not enforce unique usernames by itself?