What is Consistency

Consistency in distributed systems describes what guarantees you get when reading replicated data. If you write a value to one node, when can you read it from another node? The answer depends on the consistency model the system provides. Stronger models are easier to reason about but harder (and slower) to implement.

How it works

There is a spectrum of consistency models. The most common:

Strong consistency (also called linearizability). Every read returns the most recent write, regardless of which node you ask. The system behaves as if there is a single copy of the data. This requires coordination — typically consensus protocols like Raft or Paxos — which adds latency. etcd, ZooKeeper, and Spanner provide strong consistency.

Eventual consistency. If no new writes occur, all replicas will eventually converge to the same value. But "eventually" might mean milliseconds or minutes. In the meantime, different replicas may return different values for the same key. DynamoDB and Cassandra default to eventual consistency.

Read-your-writes consistency. A user always sees their own writes. If you update your profile, your next page load shows the update — even if it hits a different replica. Other users may see the old value temporarily. This is weaker than strong consistency but avoids the most confusing user-visible anomalies.

Causal consistency. If operation A happened before operation B (and B could have seen A), then every node sees A before B. Unrelated operations can appear in any order. This is stronger than eventual but weaker than strong, and cheaper to implement.

The CAP theorem explains the fundamental trade-off: during a network partition, you must choose between consistency and availability. Strong consistency means rejecting requests when nodes cannot communicate. Availability means accepting requests and risking stale reads.

Why it matters

Consistency determines whether your application can trust what it reads. Choosing the wrong model leads to subtle bugs: lost updates, phantom reads, stale data shown to users who just wrote it. Understanding the model your database provides lets you design around its limitations instead of discovering them in production.

See How Consistency Works for the full hierarchy of consistency models and their trade-offs.