Consistency models: strong, eventual and causal
In short: A consistency model is a promise about what reads return when data is copied across nodes. Strong models behave like a single copy but cost latency; eventual consistency is fast and available but can show stale data for a while; causal and session guarantees sit in between.
Why consistency models exist
When data is replicated to several nodes, a write reaches them at slightly different times. A consistency model is the contract that tells developers what a read may return during that window. Picking the model is one of the most important decisions in a distributed design, because it shapes both correctness and speed.
Strong models
- Linearisability (often called strong consistency): once a write completes, every later read anywhere returns it. The system behaves as if there were one copy. Leader-based systems using consensus provide this.
- Sequential consistency: all nodes see operations in the same order, and each client's operations appear in the order it issued them, but that order need not match real time.
- Serialisability is a related database term about transactions: concurrent transactions give the same result as if they ran one by one. "Strict serialisability" combines it with linearisability.
The price is coordination: nodes must talk before answering, which adds latency and reduces availability during partitions (see CAP and PACELC).
Eventual and causal models
Eventual consistency promises only that if writes stop, all replicas will converge on the same value. In the meantime reads may be stale or differ between nodes. DNS is a familiar example: a changed record spreads gradually as caches expire.
Causal consistency is a useful middle ground. If one operation could have influenced another, everyone sees them in that order. If you post a question and a friend replies, nobody sees the reply before the question. Unrelated operations can appear in different orders on different nodes.
Conflicts are possible under weaker models. Systems resolve them with rules such as last-writer-wins (simple but can lose data), version vectors that detect concurrent edits, or CRDTs (conflict-free replicated data types) that merge automatically.
Session guarantees
Users often care most about their own view. Four client-centred guarantees help:
| Guarantee | Promise | Problem it prevents |
|---|---|---|
| Read-your-writes | You always see your own updates | Saving a profile then seeing the old one |
| Monotonic reads | You never go back to older data | A comment appearing then vanishing on refresh |
| Monotonic writes | Your writes apply in the order you made them | An old edit overwriting a newer one |
| Writes-follow-reads | A write is ordered after what you read | A reply stored before its parent post |
A common technique is to route a user's reads to the leader, or to the same replica, for a short time after they write.
Choosing a model
- Ask what goes wrong if a read is stale for a few seconds.
- Use strong consistency for balances, stock, unique usernames and access rights.
- Use eventual consistency for counters, feeds, analytics and caches.
- Add session guarantees so users never see their own changes disappear.
- Document the model so developers do not assume more than it gives.
Tip: replication lag is a frequent cause of "the save did not work" support tickets. Check whether the read hit a lagging replica before blaming the application.
Practice
A user updates their address and the page immediately shows the old one. Which guarantee is missing?
Give an example of causal ordering.
Why not use linearisability everywhere?
Key takeaways
- A consistency model defines what reads may return across replicas.
- Linearisability behaves like one copy but costs latency.
- Eventual consistency converges over time and may show stale data.
- Causal and session guarantees give a practical middle ground.
- Match the model to the harm a stale read would cause.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.