Consistency Models
Updated June 6, 2026Consistency models define the rules for what a distributed system promises you will see when you read data. They matter because the same database can make very different guarantees depending on how you configure it, and picking the wrong model has real consequences.
The Core Problem
When data lives on a single server, consistency is trivial: there's one source of truth. But single servers fail and cannot handle infinite load, so we replicate data across multiple nodes. Once we do that, we face a fundamental question: when a write lands on Node A, how quickly does Node B learn about it?
The answer is never "instantly" without paying a latency cost. Light takes ~70ms to cross the Atlantic. Network coordination takes time. Every consistency model is really an answer to: how much delay and uncertainty are you willing to accept in exchange for speed and availability?
Strong Consistency
With strong consistency, after a write completes, every subsequent read from any node, anywhere, returns the updated value. There is one global version of the truth, and everyone sees it immediately.
The mechanism: the primary waits for a quorum of replicas to acknowledge the write before telling the client "done." If a read arrives while the sync is in flight, the system may block it or route it to a node that is guaranteed to have the latest data.
Strong consistency
Pros: reads are always correct: no stale data, no surprises. Cons: writes are slower (you pay the round-trip to replica nodes), and the system may become unavailable if too many replicas are unreachable (cannot form a quorum).
Where it is used: Google Spanner uses atomic clocks (TrueTime) to achieve strong consistency globally. Financial systems, inventory management, and booking platforms require it, because the cost of serving wrong data is higher than the cost of being slow.
Why does strong consistency make writes slower compared to eventual consistency?
Eventual Consistency
With eventual consistency, the primary acks writes immediately without waiting for replicas to confirm. The update propagates to replicas asynchronously in the background. If you read from a replica before it is caught up, you see the old value; given enough time with no new writes, all replicas converge.
Eventual consistency
Pros: writes are fast (sub-millisecond acks), and the system stays available even when replicas are lagging or unreachable. Cons: readers may temporarily see stale data. Applications need to handle this, or not care.
Where it is used: DynamoDB reads are eventually consistent by default. Cassandra is eventually consistent. Instagram like counts, YouTube view counters, and DNS records all use eventual consistency. The replication lag is typically milliseconds to seconds. For most of these use cases, a few seconds of staleness is completely invisible to users.
With eventual consistency, if no new writes occur, all replicas will eventually return the same value.
Read-Your-Own-Writes
Eventual consistency has an annoying edge case: you update your profile, the page refreshes, and your change appears to have vanished because the read hit a replica that has not caught up yet.
Read-your-own-writes is a consistency guarantee that fixes this specific problem. The system guarantees that you always see your own writes, even if other users might briefly see the old version.
The implementation: stamp each session with a version token after a write. On subsequent reads, the router checks whether the target replica has reached that version. If not, route the read to the primary instead. Once the replica catches up, reads go back to the replica.
Other users still read from replicas and may briefly see the old value. But from your perspective, your changes are always visible. This is what most modern web apps actually implement under the hood.
Read-your-own-writes
What problem does the read-your-own-writes guarantee specifically solve?
Which implementation detail enables the read-your-own-writes guarantee?
Choosing the Right Model
The choice is not about which model is "better"; it is about matching the model to what actually matters for a given piece of data:
Use strong consistency when: the cost of serving wrong data is real, such as double-charging a credit card, showing a sold-out product as available, or letting two users claim the same username.
Use eventual consistency when: the data is low-stakes or inherently approximate, such as social feed ordering, view counts, analytics, or search indexes. Eventual consistency dramatically reduces write latency and keeps the system available during partial failures.
Use read-your-own-writes when: you need strong consistency from the user's perspective but can afford eventual consistency from everyone else's. Profile updates, settings changes, and shopping cart edits all fall here.
Real systems use different consistency models for different data. Your payment ledger might be strongly consistent; your recommendation feed is eventually consistent. Multi-model architectures are the norm, not the exception.
DNS records and social media like counts are good candidates for strong consistency.
Production systems typically pick a single consistency model and apply it uniformly across all data.
Summary
Consistency models define what guarantees a distributed system makes about reads after writes. Strong consistency means every read sees the latest write, at the cost of coordination latency. Eventual consistency means writes are fast and the system stays available, but reads may briefly see stale data. Read-your-own-writes is a practical middle ground: you always see your own changes even if others do not immediately. Matching the consistency model to the data, rather than picking one model for everything, is the real engineering decision.
Saved on this device only
Sign in to sync progress across devices