Every distributed system makes a promise about what a read will return, and that promise is its consistency model. Pick the strongest one everywhere and you pay for coordination on every operation. Pick the weakest and you hand reconciliation work to your application, plus a class of bug that only appears under load. Most discussion treats this as strong versus eventual, missing both the middle ground and the guarantees users actually notice. This page compares the data-centric models, covers the client-centric guarantees that decide whether your application feels correct, and shows how 티DB implements them with mechanisms you can switch on per session or per statement.
What Are Consistency Models in Distributed Systems?
A consistency model is the contract a distributed system makes about which values a read can return when data is replicated across multiple nodes. It defines what ordering and recency guarantees hold, and therefore which anomalies an application must handle itself. Models range from strong consistency, where every read returns the most recent committed write, to eventual consistency, where replicas converge over time and a read may return a stale value.
The choice matters because it moves work rather than removing it. A stronger model puts coordination cost in the database, in the form of latency on reads and writes. A weaker model puts correctness cost in the application, in the form of code that reconciles conflicting values and handles users seeing data that has since changed. The wider framing sits on data consistency in distributed systems.
Data-Centric Models: Strong, Causal, and Eventual Consistency
Strong consistency, in its strictest form linearizability, means every read returns the most recently committed write, and all clients observe operations in the same order. The system behaves as though there were one copy of the data. The cost is coordination: a write needs agreement from multiple replicas before it commits, and the physical distance between those replicas sets a floor on write latency that no amount of tuning removes.
Causal consistency preserves the order of operations that are causally related, while allowing concurrent and unrelated operations to be observed in different orders on different replicas. If a reply is written after the message it answers, no client sees the reply before the message. Two unrelated comments posted at the same moment may appear in either order. This is weaker than strong consistency and considerably cheaper, because only causally linked operations need ordering, though the system must track those relationships.
Eventual consistency guarantees only that if writes stop, all replicas converge on the same value. A read may return a stale value, and two reads issued at the same moment against different replicas may disagree. It is the cheapest to operate and the most demanding to build against, since conflict resolution becomes the application’s problem.
| Model | Guarantee | Cost | Fits |
|---|---|---|---|
| Strong (linearizable) | Every read returns the latest committed write; one global order | Coordination on every write; latency floor set by replica distance | Payment ledgers, inventory counts, order books |
| Causal | Causally related operations observed in order; concurrent ones may differ per replica | Tracking causal relationships; no single global order | Comment threads, collaborative editing, messaging |
| Eventual | Replicas converge once writes stop | Conflict resolution pushed into the application | View counters, DNS, cache invalidation |
Client-Centric Consistency: What Users Actually Experience
Data-centric models describe the replicas. Client-centric models describe the session, and they are what determines whether an application feels broken.
The clearest example: a user posts a comment, the write commits, and the page refreshes. If that refresh is served by a replica that has not yet received the write, the comment is missing. The system may be perfectly within its stated guarantee. The user concludes the feature is broken and posts again.
Read-your-writes consistency rules this out. Once a client has written a value, its own subsequent reads always reflect that write, even if other clients do not see it yet. Monotonic reads is the related guarantee that a client never moves backward in time: having seen a value, it will not later see an older one, which prevents a refresh from making data disappear and reappear. Session consistency bundles these guarantees and scopes them to a session, holding while the client is connected and resetting on a new one.
These guarantees are cheaper than global strong consistency because they constrain one client’s view rather than imposing a single order on all clients. That is why they are often the right answer: they buy the behavior users notice without paying for coordination users never see.
How TiDB Applies These Models in Practice
TiDB is strongly consistent by default. Data is split into Regions, each replicated as a Raft group that commits a write only after a majority of replicas have persisted it, and reads go to the Region leader. Read-your-writes and monotonic reads hold without configuration.
Two mechanisms let you trade differently, and they trade different things.
Follower Read serves reads from follower replicas while preserving strong consistency. Before returning data, the follower performs a Raft `ReadIndex` operation against the leader to confirm the latest commit index, then applies up to that point. Snapshot Isolation is unaffected, so read-your-writes still holds. What you gain is reduced load on the leader and, in multi-zone deployments, reads served locally rather than across zones. What you pay is one extra network interaction per read and some TiKV CPU, which is why it suits large or batch reads rather than point queries. Set it with `tidb_replica_read`, where `closest-adaptive` skips Follower Read for small queries and keeps the added CPU overhead typically under 10% compared with the default leader policy.
Stale Read is the mechanism that actually relaxes recency. It reads a transactionally consistent snapshot from a past point in time, and because any replica can serve it, there is no leader interaction and no cross-zone round trip. You get a coherent view, not a current one. Read-your-writes does not hold, so a read issued immediately after a write may not see it. Apply it per statement with `AS OF TIMESTAMP`, per session with `tidb_read_staleness`, and keep it off any read path that follows a user’s own write.
That distinction is the practical version of everything above. Follower Read moves where a read is served. Stale Read moves when it is served from. Only the second one changes what your users can observe.
Both are worth measuring against your own workload. Start with TiDB Cloud Starter, free, or work through the scenarios in TiDB Labs.
Frequently Asked Questions
What is the difference between data-centric and client-centric consistency models?
Data-centric models describe what the system guarantees about the data across all replicas and clients, such as whether a single global order of operations exists. Client-centric models describe what one client observes across its own sequence of operations, such as whether it always sees its own writes. A system can satisfy a weak data-centric model while still offering useful client-centric guarantees, which is often the cheapest way to make an application behave correctly from the user’s point of view.
What is read-your-writes consistency?
Read-your-writes consistency guarantees that once a client has written a value, all of that client’s subsequent reads reflect the write, even if other clients cannot see it yet. It prevents the most visible distributed-systems bug: a user submits data, refreshes, and finds it missing because the read was served by a replica that had not yet received the write. It constrains only the writing client’s view rather than imposing a global order, which makes it substantially cheaper than full strong consistency.
Does TiDB support eventual consistency?
TiDB is strongly consistent by default and does not offer eventual consistency as a mode. Reads go to the Region leader, and writes commit only after majority agreement in the Raft group. Stale Read is the closest available option, but it is not eventual consistency: it returns a transactionally consistent snapshot from an earlier point in time rather than a possibly divergent replica value. Follower Read serves reads from followers while preserving strong consistency through a Raft ReadIndex check.
When should you choose causal consistency over strong consistency?
Choose causal consistency when your correctness requirement is about ordering rather than recency, and when the coordination cost of strong consistency is material. Messaging, comment threads, and collaborative editing need a reply never to appear before the message it answers, but they do not need every client to see every unrelated operation in the same order. Choose strong consistency when a stale or divergent read causes real damage, as with account balances, inventory counts, or anything where two clients acting on different values creates a conflict that cannot be reconciled after the fact.