Consistency Patterns

In the CAP Theorem, we established that when designing a distributed system, you often have to make a trade-off between consistency and availability during a network partition. But "consistency" itself is not a single, monolithic concept. It's a spectrum.

Understanding the different levels of consistency is crucial for choosing the right database and designing a system that behaves predictably for your users.

The Spectrum of Consistency

1. Strong Consistency (or Linearizability)

What it is: This is the strictest and most intuitive form of consistency. It guarantees that any read will return the value of the most recent successful write. Once a write is complete, all subsequent reads will see that value.

Analogy: It behaves like a single machine. There is a global, total order of operations.
System Type: This is the "C" in a CP system.
Pros: Very simple programming model. The data is always predictable.
Cons: Can have high latency because the system may need to coordinate across multiple nodes (or even datacenters) to confirm a write before it can be acknowledged. It can also lead to lower availability, as a node might have to return an error if it cannot confirm it has the latest data.
When to use it: Financial transactions, user authentication, e-commerce checkout processes—anywhere data correctness is non-negotiable.

2. Eventual Consistency

What it is: This is a much weaker consistency model that guarantees that if no new updates are made to a given data item, all accesses to that item will eventually return the last updated value.

Analogy: It's like subscribing to a magazine. You know you'll eventually get the latest issue, but you don't know exactly when it will arrive in your mailbox. Different subscribers will receive it at different times.
System Type: This is the model used by AP systems.
Pros: High availability and low latency. Writes can be acknowledged very quickly on a local node without waiting for replication to complete.
Cons: The programming model is more complex. You have to account for the possibility of reading stale data.
When to use it: Social media feeds, user comments, "likes," and other use cases where temporary inconsistency is acceptable and high availability is paramount.

Intermediate Consistency Models

Between the two extremes of strong and eventual consistency, there are several intermediate models that offer a balance of performance and correctness.

3. Causal Consistency

What it is: A stronger form of eventual consistency that preserves the order of causally related operations. If operation A causes operation B, then any process that sees operation B must also see operation A first.

Analogy: Imagine a series of replies in a forum thread. Causal consistency ensures that you will never see a reply to a comment before you see the original comment itself. However, it doesn't guarantee the order in which you see two unrelated comments.
Pros: It's a more intuitive model than pure eventual consistency and prevents many common "out-of-order" bugs, without the high cost of strong consistency.
Cons: It's more complex to implement than eventual consistency.
When to use it: Chat applications, comment threads—anywhere the causal relationship between events is important to the user experience.

4. Read-Your-Writes Consistency

What it is: A specific guarantee that once a user has written a piece of data, any subsequent reads they make will see that write (or a newer one).

Analogy: After you update your profile picture, you should see the new picture when you reload your profile page. You shouldn't see the old one.
Why it's important: This is a very common user expectation. Violating it can be jarring and lead users to think their update failed.
How it's implemented: This is often achieved by making the read request for a specific user go to the same replica that handled their write, at least for a short period of time. This is a form of session affinity or "sticky sessions."

5. Monotonic Reads Consistency

What it is: This guarantees that if you perform a series of reads, you will never see an older version of the data after you have seen a newer version. The data you see only ever moves forward in time.

Analogy: Imagine you are refreshing a stock ticker page. Monotonic reads ensure that the price of a stock will never go back in time. You might see the same price multiple times if it hasn't updated, but you won't see an older price after seeing a newer one.
How it's implemented: This is also often achieved by ensuring that a specific user always reads from the same replica.

Choosing the Right Model

In a system design interview, you are not expected to be an expert on the formal proofs of these models. However, you are expected to understand the trade-offs.

When you choose a database or a caching strategy, you should be able to answer these questions:

What level of consistency does this system provide?
What are the user-facing implications of that choice?
For a social media feed, eventual consistency is likely fine.
For a shopping cart, you need at least read-your-writes consistency (when a user adds an item, they should see it in their cart).
For the final payment processing, you need strong consistency.

Demonstrating that you can think through these different requirements and apply the appropriate consistency model to different parts of your system is a sign of a mature and thoughtful engineer.