Distributed systems keep copies of data in more than one place: primary databases, read replicas, caches, search indexes, vector indexes, event streams, analytics stores, and regional failover clusters.

Replication improves availability, read capacity, locality, and fault tolerance. It also creates a contract problem:

After a write succeeds, what is a later read allowed to return?

That contract is the consistency model.

A consistency model does not tell you whether the data is "correct" in a business sense. It tells you which histories of reads and writes the storage system is allowed to expose. That distinction matters. A system can be internally consistent and still contain a bad payment record because the application wrote the wrong value.

In practice, consistency is not one switch. A production system often uses strong consistency for money, permissions, quotas, and workflow transitions, while using weaker consistency for search, recommendations, counters, caches, and AI-derived indexes.

On a single machine, consistency is easier to reason about. There is one copy of the data, one local clock domain, and one storage engine deciding operation order.

Once data is replicated, several things can happen:

The Replication Problem

Suppose a client writes X = 5. Node 1 applies the write and replicates it to Node 3, but Node 2 is behind.

If another client reads from Node 2, should the system return X = 3, wait until Node 2 catches up, route the read elsewhere, or reject the read because freshness cannot be proven?

Different consistency models answer that question differently.

The Coordination Cost

Stronger consistency usually requires coordination. Coordination means nodes must exchange messages before acknowledging writes, serving reads, or declaring a leader healthy.

Each benefit comes with a paired cost. Later reads observe acknowledged writes, but read or write latency goes up. Stale reads become rarer, at the cost of availability during partitions.

A clearer operation order makes invariants easier to enforce, but write throughput suffers on hot keys or shards, and replication, failover, and testing all become more complex.

Weaker consistency reduces coordination, and again the benefits and costs come paired. Local or replica reads become possible, but they may return stale results. Writes can be accepted during partial failures, but the system has to detect and resolve conflicts later.

Geographic locality improves, though users may observe lag between views. Throughput for derived data goes up, but more reconciliation work moves into the application layer.

The right model is the weakest one that still protects the product's correctness requirements.

What Consistency Models Define

A consistency model is a contract between a storage system and its clients. Given a history of writes, it defines which values each read may return.

This is why vague statements like "the database is consistent" are not enough. You need to know the exact guarantee: linearizable reads, serializable transactions, causal consistency, read-your-writes, monotonic reads, eventual convergence, or something weaker.