Consistency Models

Not All Consistency Is Equal

Session 5.1 introduced the CAP theorem's definition of consistency: linearizability, where every read returns the most recent write. But linearizability is just one point on a spectrum. In practice, distributed systems offer a range of consistency models, each trading correctness for performance in different ways.

The model you choose determines what users see, when they see it, and whether the application feels broken or smooth. A banking system and a social media feed have very different consistency requirements. Picking the wrong model for your use case either wastes resources or frustrates users.

The Five Models

Strong Consistency (Linearizability)

Every read returns the value of the most recent completed write, globally. All nodes agree on the order of operations. This is what single-node databases provide naturally. In a distributed system, achieving it requires coordination between nodes on every operation, which increases latency.

Google Spanner achieves strong consistency across global data centers using synchronized atomic clocks (TrueTime). The engineering cost is extraordinary. Most systems do not need this, and most teams cannot afford it.

Eventual Consistency

If no new writes occur, all replicas will eventually converge to the same value. There is no bound on how long "eventually" takes, though in practice it is usually milliseconds to seconds. During the convergence window, different clients may read different values from different replicas.

DNS is the classic example. When you update a DNS record, it propagates across nameservers over minutes to hours. Every server eventually gets the new value, but during propagation, some clients see old data and others see new data.

Read-Your-Writes Consistency

A client always sees its own writes. After writing a value, that same client is guaranteed to read that value (or a newer one) on subsequent reads. Other clients may still see stale data. This model preserves individual user experience without requiring global coordination.

Monotonic Reads

If a client reads a value at time T, subsequent reads from that client will never return a value older than what was seen at time T. Time does not go backward for any individual reader. Without this guarantee, a user could refresh a page and see older data than what they saw a moment ago.

Causal Consistency

Operations that are causally related are seen by all nodes in the same order. If operation A causes operation B, every node sees A before B. Concurrent operations (those with no causal relationship) may be seen in different orders on different nodes.

Consider a social network where Alice posts a message and Bob replies. Causal consistency guarantees that every user who sees Bob's reply also sees Alice's original post. Without it, some users might see a reply to a message that appears not to exist.

Comparison Table

Read-Your-Writes in Action

The sequence diagram below shows how read-your-writes consistency works in a system with a primary node and a replica. The user writes to the primary, then reads. Without the guarantee, the read could hit a replica that has not yet received the write. With it, the system ensures the read either goes to the primary or to a replica that has caught up.

Implementation strategies for read-your-writes include:

• Session pinning: Route all reads from a client to the same node that handled the write.
• Write timestamp tracking: Attach a timestamp to the write acknowledgment. On reads, only accept responses from replicas at or past that timestamp.
• Read from primary: After a write, read from the primary node for a short window (e.g., 5 seconds), then fall back to replicas.

The Consistency Spectrum

These models are not isolated categories. They form a spectrum from strongest to weakest guarantees.

Stronger models are more expensive. They require more network round trips, more coordination between nodes, and more waiting. Weaker models are cheaper but push complexity to the application layer. Your code must handle stale data, conflicts, and out-of-order events.

Choosing the Right Model

The question is not which model is best. The question is which model fits your use case.

Bank transfers: Strong consistency. A customer's balance must be correct at all times. Showing stale data leads to overdrafts, double-spending, or regulatory violations.

Social media likes counter: Eventual consistency. If a post shows 4,291 likes instead of 4,293 for a few seconds, nobody notices and nobody is harmed.

User profile edits: Read-your-writes. The user who changed their profile photo should see the new photo immediately. Other users can wait a few seconds.

Comment threads: Causal consistency. A reply must appear after the comment it responds to. Showing replies before their parent comments is confusing.

Analytics dashboards: Eventual consistency. Data arriving a few seconds late is perfectly acceptable for aggregate metrics.

Further Reading

• Jepsen: Consistency Models — Interactive map of consistency models and their relationships.
• Wikipedia: Consistency Model
• Vogels, W. (2008). "Eventually Consistent." — Amazon CTO's explanation of consistency trade-offs.
• Lloyd, W. et al. "Don't Settle for Eventual: Scalable Causal Consistency for Wide-Area Storage with COPS."