Consistency Models: Eventual, Causal, Sequential & Strict
Four different promises about what a reader sees after a write — ordered from cheapest to most expensive to guarantee.
Intermediate
TopNotchNote
Notes that matter
why consistency is even a question
On a single machine, "consistency" barely needs a name — a value is whatever the last write set it to, and every reader sees that. The moment data is replicated across multiple machines (for availability and read performance), a gap opens up: a write lands on one replica first, and there's an unavoidable window where other replicas still hold the old value. Consistency models are different sets of promises about how that gap is allowed to behave.
The four models below are ordered from weakest to strongest guarantee — and, not coincidentally, from cheapest/fastest to most expensive/slowest to actually implement.
eventual consistency
Eventual consistency is the weakest model: it only promises that if writes stop coming in, every replica will eventually converge on the same value. It says nothing about how long "eventually" takes, or what a reader sees in the meantime.
This is the right choice for data where a reader seeing a slightly stale value causes no real harm. A like-count on a social post that's briefly off by a few is a classic example — nobody notices or cares, and the performance win from not coordinating every replica on every write is large.
causal consistency
Causal consistency is a step up: it distinguishes between operations that are causally related (dependent) and operations that are independent (concurrent), and guarantees that causally related operations are seen by everyone in the same order — while unrelated operations can be seen in different orders on different replicas.
The canonical example is comments on a social media post. If User A comments and User B replies to that comment, the reply is causally dependent on the original comment — every viewer must see the comment before the reply, or the conversation is nonsensical. But two independent top-level comments from different users have no causal relationship, so it's fine if different viewers see them in a different order.
sequential consistency
Sequential consistency is stronger still: every client's own operations appear in the exact order that client issued them, and all replicas agree on some single global ordering of all operations — it just doesn't have to match real-world ("wall clock") time.
A useful mental model: your friend's posts on a feed always appear in the order they posted them (respecting their program order), and everyone viewing the feed agrees on one consistent ordering of all posts — but that ordering doesn't need to exactly match the millisecond each post was created, which is a subtly weaker (and cheaper) guarantee than it might first sound.
strict consistency (linearizability)
Strict consistency, also called linearizability, is the strongest model: once any client receives acknowledgment that a write succeeded, every subsequent read from any replica, anywhere, is guaranteed to see that write or a later one. It behaves exactly as if there were only one copy of the data.
This is expensive because it usually requires coordinating with other replicas before acknowledging a write, which adds latency and can reduce availability during a network partition (see the CAP theorem). It's reserved for cases where a stale read is genuinely dangerous — changing a bank account password after detecting fraud is the standard example: every subsequent login attempt, anywhere, must see the new password immediately, not "eventually."
choosing a model in practice
| Model | Strength | Typical use case |
|---|---|---|
| Eventual | Weakest | Like counts, view counts, non-critical caches |
| Causal | Weak-to-moderate | Comment threads, chat message ordering |
| Sequential | Moderate-to-strong | Social feeds, collaborative documents |
| Strict / linearizable | Strongest | Account credentials, financial balances, inventory counts |
The general rule: default to the weakest model that the feature can tolerate, because every step up this ladder trades away availability, latency, or both. Application programmers using a strongly consistent data store are implicitly accepting that trade-off on every single write.