When we have data spread across multiple servers, the big question is: how “fresh” does the data need to be when someone reads it? The answer depends on the consistency model we choose. Different models give different guarantees, and there’s always a trade-off between correctness and performance.
The Consistency Spectrum
The further left we go, the more “correct” our reads are — but the slower and harder to scale. The further right, the faster and more available — but we might read stale data.
Strong Consistency (Linearizability)
Every read returns the most recent write. Period. If User A writes “balance = $500” and User B reads right after, User B sees $500. There’s no window where stale data is visible.
Think of it like a single database with one copy of the data. Even if there are multiple replicas behind the scenes, the system behaves as if there’s only one copy.
How it works: The system coordinates between all replicas before confirming a write. This takes time — every write waits for a majority of nodes to agree.
Examples:
- Google Spanner (uses synchronized clocks across data centers)
- CockroachDB
- Single-node PostgreSQL (trivially strong — there’s only one copy)
Best for: Bank accounts, stock trading, inventory counts — anywhere wrong data causes real damage.
Trade-off: Higher latency on writes. More coordination overhead. Less availability during partitions.
Eventual Consistency
If we stop writing, eventually all replicas will converge to the same value. But right after a write, different replicas might return different values. There’s no guarantee on when they’ll catch up — could be milliseconds, could be seconds.
Think of it like updating a Google Doc. If two people edit at the same time, each person sees their own version briefly. Eventually it all syncs up.
Examples:
- Amazon DynamoDB (default mode)
- Cassandra (with consistency level ONE)
- DNS propagation — we update a DNS record and it takes hours to propagate everywhere
Best for: Social media likes, view counts, recommendation feeds — where showing a count of 4,823 instead of 4,825 for a few seconds is perfectly fine.
Trade-off: Fast writes and high availability, but we might read stale data.
Causal Consistency
This one is clever. It preserves cause-and-effect ordering. If event A caused event B, everyone sees A before B. But unrelated events can appear in any order.
Example: I post a message “Hey, who wants pizza?” (event A), then someone replies “I do!” (event B). Causal consistency guarantees everyone sees my question before the reply. But two unrelated posts from different users can appear in any order.
Examples:
- MongoDB (with causal sessions)
- Some configurations of Cassandra
Best for: Comment threads, chat applications — where ordering within a conversation matters but global ordering doesn’t.
Read-Your-Writes Consistency
After we write something, we are guaranteed to see our own write. Other users might see stale data temporarily, but the person who made the change always sees it reflected.
This solves the classic problem: a user updates their profile name, refreshes the page, and sees the old name. Infuriating. With read-your-writes, that doesn’t happen.
How to implement it:
- Route the user’s reads to the same replica that processed their write
- After a write, read from the primary for a few seconds
- Include a timestamp token — only accept reads from replicas that are at least that fresh
Best for: User profile updates, settings changes — anywhere the “I just changed this, why doesn’t it show?” experience is bad.
Monotonic Reads
Once we’ve read a value, we never see an older value on subsequent reads. Our reads only move forward in time, never backward.
Without this, a user might refresh a page and see their feed go backward — posts disappear and reappear. That happens when successive reads hit different replicas at different replication states.
How to implement: Use sticky sessions — route a user to the same replica consistently.
How Real Systems Handle This
Most databases let us tune consistency per operation. We don’t have to pick one model for everything.
| System | Default | Tunable? |
|---|---|---|
| PostgreSQL | Strong (single node) | N/A for single node |
| DynamoDB | Eventual | Yes — strongly consistent reads available |
| Cassandra | Tunable per query | ONE (eventual) to ALL (strong) |
| MongoDB | Strong for primary reads | Read preferences for replicas |
| CockroachDB | Serializable (strongest) | Can weaken for performance |
Picking the Right Model
The decision comes down to two questions:
1. What happens if a user reads stale data?
- Nothing bad → eventual consistency is fine
- Confusion or bad UX → read-your-writes
- Financial loss or data corruption → strong consistency
2. How much latency can we tolerate?
- Milliseconds matter → eventual consistency (fastest)
- Some latency is OK → causal or read-your-writes
- Correctness over speed → strong consistency
A Practical Example
Imagine we’re building an e-commerce platform:
- Product catalog (price, description) → Eventual consistency. If a price update takes a second to propagate, nobody gets hurt.
- User sessions → Read-your-writes. A user logs in and should immediately see their cart.
- Inventory count → Strong consistency. We can’t sell 5 items when only 3 are in stock.
- Review counts → Eventual consistency. Showing “142 reviews” when it’s actually 143 for a few seconds is harmless.
Different parts of the same system can (and should) use different consistency models.
Key Takeaway
In simple language, consistency models are about how fresh our data needs to be when someone reads it. Strong consistency means always fresh — but slow. Eventual consistency means sometimes stale — but fast. Most real systems mix and match: strong where it matters (money, inventory), eventual where it doesn’t (likes, views). The skill is knowing which parts of our system need which guarantee.