Understanding Consistency Models

Hello! Welcome to the third lesson in our course on Distributed Systems Architecture.

In our last session, we established that due to network delays and clock drift, we cannot rely on physical clocks for ordering events. This led us to the "happens-before" relation, which defines a partial order based on causality. This partial order is the "natural" state of a distributed system, but it leaves a crucial question unanswered: what about events that are concurrent? How should the system present them to users?

Today's lesson directly addresses that question. We will explore the different guarantees, or "contracts," that a distributed system can offer about how it orders operations and makes them visible across replicas.

Learning Outcome:

Define and differentiate between linearizability, sequential consistency, causal consistency, and eventual consistency, providing practical examples for each.

These four models represent a spectrum of trade-offs between the ease of programming (strong consistency) and high performance/availability (weak consistency). Understanding this spectrum is fundamental to designing and reasoning about any distributed system.

1. The Consistency Spectrum: Strong vs. Weak

When data is replicated across multiple nodes, we need a rulebook—a consistency model—that defines what guarantees a client can expect when reading and writing data. These models range from "strong" (behaving like a single, non-distributed machine) to "weak" (prioritizing speed and availability over strict ordering).

To get a high-level overview of this landscape, let's start with a reading that groups the models and provides clear, initial definitions.

As the article explains, the choice of a consistency model is a fundamental architectural decision that impacts everything from user experience to system performance. Let's now dissect each of the four main models, starting with the strongest.

2. Linearizability: The "Single-Copy" Illusion

Linearizability, also called strong or strict consistency, is the most intuitive and stringent model. It makes a distributed system behave as if there is only one copy of the data and every operation is atomic.

Definition: An operation is linearizable if it appears to take effect instantaneously at some single point in time between its invocation and its completion. This implies a total ordering of all operations that is consistent with their real-time occurrence.

The key idea is recency: once a write operation completes, any read operation that begins after the write completes must see the value of that write (or a later one).

To get a deeper intuition, we'll turn to a video by Martin Kleppmann, a leading expert in this field.

Practical Example: Financial Systems

Your experience at Revolut with FX trading and settlement systems provides perfect examples of where linearizability is non-negotiable.

• Trade Execution: When a trade is executed, its price and volume must be immediately and consistently visible to all parts of the system (risk management, accounting, client-facing UIs). You cannot have a situation where the risk system sees an old price while the settlement system sees the new one.
• Account Balances: A user's account balance must be linearizable. If a user makes a deposit, any subsequent balance check must reflect that deposit. A system that shows a pre-deposit balance after the deposit has been confirmed is broken.

Achieving linearizability often requires consensus protocols (which we'll cover in a future lesson) and can introduce latency, as the system must coordinate to ensure all nodes agree on the state before responding to a client.

3. Sequential Consistency: A Step Down

Sequential consistency is slightly weaker than linearizability. It relaxes the real-time constraint but still provides a strong guarantee.

Definition: The result of any execution is the same as if all operations by all processes were executed in some single sequential order, and the operations of each individual process appear in this sequence in the order specified by its program.

The Difference: With sequential consistency, all processes agree on the same total order of operations. However, that order might not match the real-time order of when those operations occurred. The only constraint is that the order must preserve the program order for each client.

Practical Example: Collaborative Editing

Imagine a simple collaborative document editor.

• You type "Hello".
• Then you type " world".
  Sequential consistency guarantees that everyone else will see "Hello" appear before " world". Your local program order is preserved.
• However, if a collaborator types "Goodbye" at the same real-world time you type "Hello", other users might see the final text as "Goodbye Hello world" or "Hello Goodbye world". The system picks one valid interleaving and shows it to everyone. Linearizability would require the order to match who "pressed enter" first in real-time.

4. Causal Consistency: Preserving the Flow of Logic

Causal consistency directly builds on the "happens-before" relationship from our last lesson.

Definition: If operation A causally precedes operation B (A → B), then any process that sees operation B must first see operation A. Operations that are not causally related (i.e., are concurrent) can be seen in different orders by different processes.

This model is a natural fit for many applications where the chain of cause-and-effect is what truly matters.

Practical Example: Social Media Comments

• User A posts a comment: "What is the best consistency model?"
• User B replies to User A: "Linearizability, for sure."
• User C, at the same time, posts a new, independent comment: "I like eventual consistency."

Causal consistency guarantees that everyone will see User A's original comment before User B's reply. The reply is causally dependent on the original post. However, User C's comment is concurrent. Some people might see the order: A, C, B. Others might see: A, B, C. Both are valid under causal consistency because the causal link (A → B) is preserved.

5. Eventual Consistency: Prioritizing Availability

This is the weakest model on our spectrum and is widely used in systems that need to be highly available and scalable.

Definition: If no new updates are made to a data item, all replicas will eventually converge to the same value. The system gives no guarantees about the order of operations or how long this convergence will take, only that it will happen.

During the convergence period, it's possible—and expected—for different clients to read different, stale values from different replicas.

Practical Example: DNS and Content Delivery Networks (CDNs)

• DNS: When you update a DNS record (e.g., pointing a domain to a new IP address), it can take hours for that change to propagate across all DNS servers on the internet. During that time, some users will be directed to the old IP and some to the new one. The system is eventually consistent.
• YouTube View Counts: The view counter on a video doesn't update in real-time for every single viewer across the globe. It would be incredibly inefficient. Instead, views are aggregated and updated periodically. It's acceptable for the count to be slightly out of date.

To make eventual consistency more user-friendly, systems often provide weaker, client-centric guarantees, such as Read-Your-Writes, which ensures that once you've made an update, you will always see your own update, even if other users don't see it yet.

6. Summary and Comparison

The four models form a hierarchy of guarantees. A system that is linearizable is also sequentially consistent, which is also causally consistent. Eventual consistency stands apart as the weakest model.

Let's consolidate everything with a final reading and a summary table.

Here is a summary table inspired by the resources, putting all the models side-by-side:

Conclusion

In this lesson, we have defined and differentiated the four primary consistency models that govern the behavior of replicated data in distributed systems.

Key Takeaways:

• Consistency models are contracts that define how a system orders operations and makes them visible to clients.
• Linearizability offers the strongest guarantee, making the system appear as a single, real-time, atomic unit. It's essential for correctness in systems like banking but comes at a high performance cost.
• Sequential Consistency relaxes the real-time requirement but ensures all clients see the same total order of events.
• Causal Consistency focuses on preserving the "happens-before" relationship, which is often sufficient for collaborative applications.
• Eventual Consistency prioritizes availability and performance, allowing temporary inconsistencies with the promise that replicas will converge over time.
• Choosing a consistency model is a core architectural decision that involves a trade-off between correctness, performance, availability, and developer complexity.

Preview of the Next Lesson:
We've repeatedly mentioned the trade-off between consistency and availability. In the next lesson, we will formalize this tension with one of the most famous principles in distributed computing: the CAP Theorem. We will explore what it means to be Consistent (C), Available (A), and Partition-Tolerant (P), and why a distributed system can only choose two out of three. We will then look at its practical extension, the PACELC theorem.