Consistency in System Design: Models, Trade-offs and Examples
Consistency in system design describes whether everyone who reads a piece of data sees the same, up-to-date value. On a single database server this is easy. Once data is copied across several servers, caches or regions, copies can briefly disagree, and the system must decide what readers are allowed to see. That decision is captured by a consistency model.
This tutorial explains why consistency is hard in distributed systems, walks through the main consistency models from strongest to weakest, and shows the techniques databases use to provide them. It ends with common mistakes and best practices.
1. What Is Consistency?
Imagine a bank account shown in a mobile app, on the website and at an ATM. You withdraw ₹2,000 at the ATM. A consistent system shows the new balance everywhere immediately. An inconsistent system might still show the old balance in the app for a few seconds, which could let you spend the same money twice.
In distributed systems, consistency answers one question: after a write, what will later reads return?
- With strong consistency, every read returns the latest successful write, no matter which server answers.
- With weaker consistency, reads may return older values for a while, in exchange for speed and availability.
Note that the word appears in two different places. The "C" in CAP means the replica-agreement kind of consistency described here. The "C" in ACID means something else: that a transaction keeps data valid according to rules such as constraints. See ACID vs BASE for that meaning.
2. Why Consistency Is Hard in Distributed Systems
Large systems keep several copies of data: database replicas for read scaling and availability, caches for speed, and copies in multiple regions for low latency. Copying takes time, so for a moment after every write, some copies are newer than others.
Several forces make perfect consistency expensive:
- Network delay: confirming a write with replicas in another region can add tens or hundreds of milliseconds.
- Failures and partitions: if replicas cannot talk to each other, the system must either stop accepting some requests or let copies diverge. This is the CAP theorem.
- Concurrency: two users can update the same data at the same moment through different servers.
- Caching: every cache is another copy that can go stale.
3. Consistency Models from Strongest to Weakest
A consistency model is a contract between a data system and its users: it promises which values reads may return. Stronger models are easier to program against; weaker models are faster and more available.
| Model | Guarantee | Everyday example |
|---|---|---|
| Linearizable (strong) | The system behaves as if there is one copy; once a write completes, every later read sees it | Bank balance, seat booking, unique usernames |
| Sequential | All clients see operations in the same order, though not necessarily in real-time order | A shared log that everyone replays identically |
| Causal | Operations that are causally related are seen in the same order by everyone; unrelated ones may be seen in any order | A reply never appears before the message it answers |
| Read-your-writes | A user always sees their own latest changes | After editing your profile, you see the new photo |
| Monotonic reads | Once you have seen a value, you never see an older one later | A comment you saw does not vanish when you refresh |
| Eventual | If writes stop, all copies converge to the same value eventually | Like counts, view counts, DNS records |
4. Strong Consistency Explained
With strong consistency (formally linearizability), the system acts as if there were a single copy of the data and every operation happened at one instant. If Alice's write finishes at 10:00:00.000, anyone who reads after that moment, from any server, sees Alice's value.
Systems provide strong consistency by making writes and reads coordinate:
- All reads and writes go through a single leader, which always has the latest data.
- Writes are confirmed only after a majority of replicas agree, using a consensus protocol such as Raft or Paxos.
- Writes use synchronous replication, so replicas are updated before the client gets a success response.
Cost: every write waits for coordination, which adds latency, especially across regions. During network partitions, part of the system must refuse requests to avoid returning stale data.
5. Eventual Consistency Explained
With eventual consistency, a write is accepted by one or a few replicas and spread to the others in the background. For a short window, different readers may see different values. If no new writes arrive, all replicas eventually agree.
In a healthy system this window is usually milliseconds to a few seconds. Eventual consistency gives:
- Low latency: writes and reads are answered by a nearby replica without waiting for others.
- High availability: replicas keep working even when they cannot reach each other.
- Easy scaling: adding replicas does not slow down writes.
The trade-off is that the application must cope with stale reads and concurrent conflicting writes, for example by using last-write-wins rules, merging changes or special data types called CRDTs. Eventual consistency is the "E" in BASE.
6. Session Guarantees: The Practical Middle Ground
Pure eventual consistency can confuse users, while strong consistency everywhere is expensive. Session guarantees fix the most visible problems for each user without paying for global strong consistency:
- Read-your-writes: after you change something, your own reads always reflect it. Others may still see the old value briefly.
- Monotonic reads: your view never goes backwards in time. Without it, refreshing a page could make a new comment disappear because you hit a lagging replica.
- Monotonic writes: your writes are applied in the order you made them.
- Writes follow reads (causal): if you reply to a comment, everyone who sees your reply can also see the comment.
7. Techniques for Achieving Consistency
| Technique | How it works | Gives you |
|---|---|---|
| Single leader for reads and writes | One node handles all operations for a piece of data | Strong consistency; the leader can become a bottleneck |
| Synchronous replication | Writes wait until replicas confirm | No stale replicas; higher write latency |
| Quorum reads and writes | With N replicas, write to W and read from R where R + W > N | Reads overlap the latest write; tunable per request |
| Consensus (Raft, Paxos) | A majority must agree on the order of operations | Linearizable, fault-tolerant logs and metadata |
| Version numbers and vector clocks | Each value carries a version; clients and replicas compare versions | Detects stale data and concurrent writes; enables read-your-writes |
| Sticky routing | A user's reads go to the same replica, or to the leader for a short time after a write | Monotonic reads and read-your-writes |
| CRDTs | Data types such as counters and sets that merge concurrent updates automatically | Eventual consistency without conflicts |
| Cache invalidation | Delete or update cached entries when data changes; use short TTLs | Fewer stale reads from caches |
Quorums are explained with a diagram in the CAP Theorem tutorial.
8. Consistency vs Availability vs Latency
Consistency always competes with two other goals:
- Availability: the CAP theorem says that during a network partition you must choose between consistency and availability.
- Latency: the PACELC theorem adds that even without failures, stronger consistency costs latency, because replicas must coordinate. A write that must be confirmed in Mumbai and Frankfurt cannot be faster than the round trip between them.
This is why large systems rarely use one consistency level for everything. They choose strong consistency for data where mistakes are costly, and weaker models where speed and availability matter more. See Availability and Latency.
9. Common Mistakes to Avoid
- Reading just-written data from a replica, causing "my change disappeared" bug reports.
- Assuming caches are always fresh; forgetting to invalidate them on writes, or setting very long TTLs on data that changes.
- Using eventual consistency for money or inventory without a strongly consistent step for the critical decision.
- Demanding strong consistency everywhere, which makes the system slow and less available for no business benefit.
- Confusing ACID consistency with CAP consistency when discussing requirements.
- Ignoring concurrent writes in eventually consistent systems, so updates silently overwrite each other.
- Not monitoring replication lag, so stale reads grow unnoticed during heavy load.
10. Best Practices
- Classify data by the cost of staleness, and choose the weakest model that is still correct for each feature.
- Use strong consistency for decisions that cannot be undone, such as charging money or confirming the last seat.
- Provide read-your-writes and monotonic reads for user-facing data, even in eventually consistent systems.
- Use version numbers or timestamps so clients and services can detect stale or conflicting data.
- Design conflict resolution up front: last-write-wins, merge rules or CRDTs.
- Monitor replication lag and cache hit rates, and alert when lag grows.
- Make the user experience honest about delays, for example "your changes may take a few seconds to appear everywhere".
11. Summary
- Consistency defines what reads return after a write when data has multiple copies.
- Models range from linearizable (behaves like one copy) through causal and session guarantees to eventual consistency.
- Stronger models are easier to reason about but cost latency and availability; weaker models are faster but expose stale data.
- Techniques include leaders, synchronous replication, quorums, consensus, versioning, sticky routing and CRDTs.
- Choose consistency per feature, based on the cost of showing old data.
Good consistency design gives users correct answers where it matters and fast answers everywhere else. Open the FAQ tab for answers to common questions about consistency.
Frequently Asked Questions (FAQ)
Q1. What is consistency in system design?
Consistency describes whether all users and servers see the same, latest value of a piece of data. In distributed systems with multiple copies, it defines what a read can return after a write, from always the latest value to possibly older values for a short time.
Q2. What is a consistency model?
A consistency model is a contract between a data system and its clients that specifies which values reads may return, given the writes that have happened. Examples include linearizable, sequential, causal, read-your-writes and eventual consistency.
Q3. What is strong consistency?
Strong consistency, or linearizability, means the system behaves as if there were a single copy of the data. Once a write completes, every later read from any server returns that value or a newer one.
Q4. What is eventual consistency?
Eventual consistency means replicas may temporarily return different values, but if no new writes arrive, all replicas eventually converge to the same value. It favours availability and low latency over immediate agreement.
Q5. What is the difference between strong and eventual consistency?
Strong consistency guarantees every read sees the latest write, at the cost of coordination latency and reduced availability during failures. Eventual consistency allows stale reads for a short time but responds faster and stays available even when replicas cannot communicate.
Q6. What is read-your-writes consistency?
Read-your-writes guarantees that after a user writes data, that same user always sees their write in subsequent reads, even if other users may briefly see older values. It is usually implemented by reading from the primary or from a replica that has caught up to the user's last write.
Q7. What is causal consistency?
Causal consistency ensures that operations that depend on each other are seen in the same order by everyone. For example, a reply to a message is never visible to anyone before the original message. Unrelated operations may be seen in different orders.
Q8. What are monotonic reads?
Monotonic reads guarantee that once a client has seen a particular version of data, it will never later see an older version. This prevents data from appearing to go backwards in time when consecutive requests hit different replicas.
Q9. Why does replication cause consistency problems?
Copying writes to replicas takes time, especially with asynchronous replication across regions. During that time, replicas hold older data, so reads served by them return stale values. This delay is called replication lag.
Q10. How is consistency related to the CAP theorem?
The C in CAP refers to strong consistency between replicas. The CAP theorem states that during a network partition, a distributed system must choose between staying consistent (refusing some requests) and staying available (possibly returning stale data).
Q11. Is consistency in CAP the same as in ACID?
No. CAP consistency is about replicas agreeing on the latest value. ACID consistency is about a transaction keeping the database valid according to its rules, such as constraints and foreign keys. They are different concepts that share a name.
Q12. What is linearizability?
Linearizability is the formal name for the strongest single-object consistency model. Every operation appears to take effect instantly at some point between its start and end, and all clients observe operations in an order consistent with real time.
Q13. How do quorums provide consistency?
With N replicas, a write must be acknowledged by W replicas and a read must query R replicas. If R + W > N, every read group overlaps every write group, so at least one replica in each read holds the latest write.
Q14. How do you handle conflicts in eventually consistent systems?
Common strategies are last-write-wins using timestamps, merging concurrent changes, using conflict-free replicated data types (CRDTs) such as counters and sets, or keeping both versions and letting the application or user resolve them.
Q15. Which consistency model should I use for payments?
Strong consistency. Payment, balance and other money-related operations must never act on stale data, so use transactions on a primary database or a strongly consistent distributed database, even if it adds some latency.
Q16. Is eventual consistency acceptable for social media?
Yes, for most features such as like counts, follower counts and feeds, where a short delay is harmless. User-facing features should still provide read-your-writes, so people see their own posts and edits immediately.
Q17. How do caches affect consistency?
Every cache is an extra copy of data that can become stale. Use TTLs, invalidate or update cache entries when the underlying data changes, and avoid caching data that must always be current, or cache it only very briefly.
Q18. How can I tell if my system has consistency problems?
Typical symptoms are users reporting that changes "disappear" after saving, values that flip between old and new on refresh, duplicate actions such as double bookings, and growing replication lag in monitoring. Testing reads immediately after writes under load also reveals them.
Q19. Does stronger consistency always mean slower performance?
Generally yes, because replicas must coordinate before confirming operations, which adds network round trips. Within one data centre the cost may be small, but across regions it can add tens to hundreds of milliseconds per write.
Q20. How should I discuss consistency in a system design interview?
Explain the models briefly, then classify the system's data by the cost of staleness: strong consistency for money and unique resources, session guarantees for user-facing edits, eventual consistency for counters and feeds. Mention how you would implement each and how replication lag and caches affect it.