System DesignConsistency is a dial, not a switch. Picking the right level for each feature is one of the most important decisions you will make.
The consistency spectrum
| Consistency Level | Guarantee | Latency | Cost | Example Use Case |
|---|---|---|---|---|
| Strong (Linearizability) | Every read returns the latest write | High | Very high | Bank transfers, inventory counts |
| Sequential | All operations appear in some total order consistent with each client's order | Medium-high | High | Distributed locks, leader election |
| Causal | Operations that are causally related are seen in order; concurrent operations may appear in any order | Medium | Medium | Chat messages, comment threads |
| Read-your-writes | A client always sees its own writes | Low-medium | Low-medium | User profile updates, form submissions |
| Eventual | All replicas converge to the same value, eventually | Low | Low | Like counts, view counters, DNS |
Strong consistency (linearizability)
The system behaves as if there is a single copy of the data. Every read returns the value of the most recent completed write.
Timeline:
Client A: Write(balance = 100) --completes-->
Client B: Read(balance) --> 100 (guaranteed)
Never this:
Client A: Write(balance = 100) --completes-->
Client B: Read(balance) --> 50 (impossible with strong consistency)Systems achieve this through consensus protocols like Paxos or Raft. Every write must be acknowledged by a majority of nodes before it is committed. The cost is real: Google Spanner uses synchronized atomic clocks (TrueTime) and still has write latencies of 10-15ms within a region.
When to use it: Financial transactions, inventory management, booking systems, anything where stale data causes real harm.
Eventual consistencyWhat is eventual consistency?A guarantee that all copies of data will converge to the same value given enough time, rather than being instantly synchronized after every write.
The most relaxed guarantee: if you stop writing, all replicas converge to the same value. In practice, convergence usually takes milliseconds to seconds.
Timeline:
Client A: Write(likes = 42) to Replica 1
Client B: Read(likes) from Replica 2 --> 41 (stale, but OK for likes)
... 200ms later ...
Client B: Read(likes) from Replica 2 --> 42 (caught up)Writes go to one node and replicate asynchronously. During the replication window, different clients may see different values.
When it is fine: Like counts, analytics data, DNSWhat is dns?The system that translates human-readable domain names like google.com into the numerical IP addresses computers use to find each other. propagation, CDNWhat is cdn?Content Delivery Network - a network of servers around the world that caches your files and serves them from the location closest to the user, making pages load faster. content delivery, search indexes.
When it is dangerous: Bank balances, limited inventory, seat reservations, unique username registration, security permission revocation.
Causal consistency
Preserves cause-and-effect: if operation A influenced operation B, everyone sees A before B. Concurrent (unrelated) operations can appear in any order.
Causal relationship:
Alice posts: "Anyone want to grab lunch?" (Message 1)
Bob replies: "Sure, where?" (Message 2, caused by Message 1)
Guarantee: Everyone sees Message 1 before Message 2.
Concurrent (no causal link):
Alice posts: "Anyone want to grab lunch?"
Carol posts: "Check out this article"
No guarantee on ordering - they're unrelated, and that's fine.This is the sweet spot for collaborative applications: chat, social feeds, document editors. You preserve logical ordering without paying the full cost of strong consistency. MongoDB (since 3.6) supports causal consistency sessions.
Read-your-writes consistency
A client always sees its own writes. You update your profile picture, refresh the page, and see the new picture, even if other users briefly see the old one.
You: Update(avatar = new_photo.jpg) --> OK
You: Read(avatar) --> new_photo.jpg (guaranteed, you see your own write)
Others: Read(avatar) --> old_photo.jpg (may be stale briefly)Cheap to implement: route reads from a client to the replica that received their write, or track write timestamps and only return reads at least that fresh. This eliminates the most confusing UX, making a change that seems like it did not work.
Mixing consistency levels in practice
Real systems choose per feature. Here is how an e-commerce platform might break it down:
| Feature | Consistency Level | Why |
|---|---|---|
| Product inventory | Strong | Overselling is expensive and damages trust |
| Order processing | Strong | Double-charging or lost orders are unacceptable |
| Product reviews | Eventual | A review appearing a few seconds late is fine |
| Shopping cart | Read-your-writes | User must see items they just added, others don't need to |
| Chat with support | Causal | Messages must appear in conversation order |
| Payment processing | Strong | Money must be handled with the strongest guarantees |
| Search results | Eventual | Index lag of a few seconds is acceptable |
The cost of strong consistency
Eventual --> 1-5ms reads (read from nearest replica)
Causal --> 5-20ms reads (may need to check ordering)
Strong --> 20-100ms reads (must confirm with majority)
These numbers are hand-wavy but directionally correct for
a multi-region deployment.At 100,000 reads per second, the difference between 2ms and 50ms per read is the difference between 10 servers and 250 servers. Default to the weakest consistency level that is safe for each feature.
How to choose
- What happens if a user sees stale data for 1 second? If "nothing bad," use eventual consistencyWhat is eventual consistency?A guarantee that all copies of data will converge to the same value given enough time, rather than being instantly synchronized after every write..
- Does the operation involve money, inventory, or security? If yes, use strong consistency.
- Does ordering between related operations matter? If yes, use causal consistency. If only the writer's experience matters, read-your-writes is enough.