Consistency patterns define how and when data updates are visible across nodes in a distributed system. Choosing the right consistency model is crucial to building systems that are both correct and performant.
After any write completes, all subsequent reads — on any node — see that write. The system behaves as if there's a single copy of the data.
How it works: All writes must be acknowledged by all (or a quorum of) nodes before returning to the client. Reads are coordinated to return only confirmed data.
Trade-off: Higher latency, lower availability (during partitions, must refuse to serve stale data)
Use when: Data correctness is critical — bank balances, inventory counts, user authentication
Technologies: etcd, Zookeeper, Google Spanner, PostgreSQL with synchronous replication
Replicas will converge to the same value — but not immediately. After a write, other nodes may temporarily serve stale data until replication catches up.
How it works: Writes are applied to one node and asynchronously propagated to others. Reads may return old data while replication is in progress.
Trade-off: Lower latency, higher availability, but temporary inconsistency
Use when: Slight staleness is acceptable — social feeds, product recommendations, caches, analytics
Technologies: Cassandra, DynamoDB, DNS, CDNs
After a user writes data, they always see their own write on subsequent reads — even if other users might still see the old value.
Why it matters: Users notice when they update their profile photo and then reload the page to see the old one. It feels broken.
Implementation strategies:
Once a user reads a value, they won't see an older value on subsequent reads. Prevents confusing time-travel effects.
Example of violation: You see a comment, refresh the page, and the comment disappears (because the second request hit a less-up-to-date replica).
Implementation: Route each user's reads to the same replica consistently (via user ID-based routing).
Operations that are causally related appear in the correct order to all nodes. Unrelated operations may appear in any order.
Example: If you post a reply to a message, no one should be able to see your reply without first seeing the original message.
Implementation: Vector clocks or version vectors track causal relationships between operations.
Data may be stale, but only up to a defined bound (e.g., reads lag behind writes by no more than T seconds or N versions).
Azure Cosmos DB offers this as an explicit consistency level — a pragmatic compromise between strong consistency and pure eventual consistency.
| Use Case | Recommended Model | |---|---| | Bank transfers, inventory | Strong consistency | | User profile updates | Read-your-writes + monotonic reads | | Social media feeds | Eventual consistency | | Collaborative editing | Causal consistency or OT/CRDTs | | Leaderboards (approximate OK) | Eventual consistency | | Distributed config/locks | Strong consistency (etcd) |