Consistency Models

A consistency model is a contract between a distributed data store and its clients about what results a read is allowed to return relative to prior and concurrent writes. It is easy to think of 'consistency' as a single on/off property, but in practice it is a spectrum with well-defined points along it, each with different guarantees, different implementation costs, and different impacts on latency and availability. At the strong end, linearizability makes a distributed system behave as if there were only a single copy of the data, with every operation appearing to take effect instantaneously at some point between its start and end. At the weak end, eventual consistency only guarantees that if writes stop, all replicas will eventually converge — with no promise about how long that takes or what an in-flight read might see. Choosing the right model for each piece of data is one of the most consequential decisions in distributed systems design because it directly trades off correctness guarantees against latency and availability.

Linearizability is the strongest common consistency model: it guarantees that every operation appears to execute atomically at some instant between its invocation and its completion, and that all clients see operations in an order consistent with real (wall-clock) time. This means once a write completes, every subsequent read by any client, anywhere, must see that write or a later one — there is no window where a client can observe stale data. Sequential consistency is slightly weaker: all clients see operations in the same order, but that order does not have to match real-time invocation order, only the program order of each individual client. Linearizability is what most people mean colloquially by 'strong consistency,' and it typically requires consensus protocols or a single authoritative source of truth per piece of data, which adds latency because writes must be acknowledged by a quorum before they are considered durable.

Between the strong and weak extremes sit useful intermediate models. Causal consistency guarantees that operations which are causally related (e.g., a reply to a comment) are seen by every observer in the same order, while concurrent, causally-unrelated operations may be seen in different orders by different clients — this is cheaper to implement than linearizability because it doesn't require global ordering, only tracking of causal dependencies (often via vector clocks). Session guarantees like read-your-writes (a client always sees its own prior writes), monotonic reads (a client never sees data go 'backwards' in time), and monotonic writes (a client's writes are applied in the order it issued them) are practical, client-scoped consistency properties that make eventually-consistent systems feel much less surprising to end users, even without paying for global strong consistency.

The right consistency model depends on what an incorrect read actually costs the business. Inventory counts for a flash sale, bank balances, and distributed locks typically need linearizability or at least strong-enough guarantees to prevent overselling or double-spending. Social media likes, view counts, and non-critical denormalized caches can tolerate eventual consistency because a momentarily wrong number causes no real harm and self-corrects. Many systems implement 'tunable consistency,' where the client specifies per-request how many replicas must acknowledge a write (W) and how many must be read (R) — when W + R > N (total replicas), you get strong consistency for that operation; when W + R <= N, you get better latency/availability at the cost of possibly stale reads. This lets a single database serve both use cases from the same cluster.