Hello! Welcome to the first lesson in our course on advanced distributed systems. Given your experience building distributed applications, you've already grappled with the practical implications of data consistency, for instance, when implementing the Saga pattern in your ride-booking project.
Our goal in this first module is to formalize that practical knowledge into a rigorous theoretical framework that you can articulate clearly in a senior engineering interview. This lesson kicks things off by focusing on the most fundamental concept: the spectrum of consistency models. We will classify and analyze the trade-offs between four key models—linearizability, sequential, causal, and eventual consistency. By the end, you'll be able to confidently explain not just what they are, but why you would choose one over the other based on system requirements.
1. The Consistency Spectrum: More Than Just "Strong" vs. "Eventual"
In distributed systems, "consistency" refers to the guarantees a system provides about the visibility and ordering of operations (reads and writes) across multiple data replicas. It’s not a binary choice but a spectrum of possibilities, each with profound implications for performance, availability, and developer complexity.
Choosing a consistency model is one of the most critical decisions in system design. As you prepare for senior-level interviews, being able to reason about these trade-offs is paramount. To start, let's get a high-level view of why this matters and what the spectrum looks like.
Consistency Patterns in Distributed Systems | Layrs
Please read the "Core Concept" section from the Layrs article. It provides an excellent, interview-focused overview of the consistency spectrum and its direct relationship with the CAP theorem.
Focus on the text from the core concept. Pay close attention to the diagram illustrating the spectrum and how it maps to the trade-offs between latency, availability, and coordination.
As the article highlights, moving towards stronger consistency requires more coordination between replicas. This coordination introduces latency and can reduce the system's availability, especially during network partitions. Conversely, weaker consistency models prioritize availability and performance by reducing this coordination, at the cost of replicas temporarily diverging.
This can be visualized as a hierarchy:
Your work with Kafka for asynchronous processing implicitly favored availability and performance (leaning towards the bottom of this hierarchy), while your use of a transactional database like PostgreSQL for core data likely leveraged strong consistency (the top of the hierarchy).
2. Strong Consistency: Linearizability
The gold standard for strong consistency is linearizability. It's the most intuitive model because it makes a distributed, replicated system behave as if it were a single, non-replicated system.
To get a precise understanding, let's turn to a leading expert in the field, Martin Kleppmann.
Distributed Systems 7.2: Linearizability
This video provides a very clear definition of linearizability and, crucially, distinguishes it from a related but different concept: serializability.
Please watch the first part of the video, from the beginning to the introduction. Note the core idea: the system behaves as if there's only a single copy of the data, and operations appear to be atomic. Also, pay attention to the important distinction made between linearizability (about single operations on a single object) and serializability (about groups of operations in transactions).
The key guarantee of linearizability is that if operation A completes before operation B begins, then operation A must appear to have executed before operation B in the system's history. This is what Kleppmann refers to as a "real-time" dependency. Any read is guaranteed to see the result of the most recent completed write.
To formalize this, let's look at the academic definition.
[PDF] Consistency Models - cs.Princeton
These lecture slides from Princeton University offer a more formal, academic definition of linearizability.
On slide 2, review the formal definition. Then, look at the examples on slides 4 through 8. Try to reason about why the histories shown are or are not linearizable based on the "real-time ordering" rule. This sharpens the intuition you gained from the video.
While linearizability is simple for developers to reason about, it comes at a significant cost. The coordination required (e.g., using consensus algorithms like Raft, which we'll cover later) introduces latency and can make the system unavailable if a quorum of replicas cannot be reached. This is the trade-off in action.
3. Weaker Consistency Models
Because strong consistency can be expensive and brittle, many systems opt for weaker models that offer better performance and availability. Let's explore the main alternatives.
Sequential Consistency
Sequential consistency is a small but important step down from linearizability. It still guarantees that all processes see the same total order of operations. However, it drops the real-time constraint.
The guarantee is that the observed order is consistent with the order of operations issued by each individual process. Operations from different processes can be interleaved in any valid way.
[PDF] Consistency Models - cs.Princeton
Let's return to the Princeton slides to see the direct comparison between linearizability and sequential consistency.
Read the definition on slide 12, under the main heading. The key phrase is "preserves the process ordering". Then, look at the comparison on slide 14 and the example on slide 15 which shows a history that is sequentially consistent but not linearizable.
An execution is sequentially consistent if operations appear to execute in some sequential order, and the operations for each individual process appear in the order they were issued by that process. This order might not reflect the real-time order of when operations occurred across different processes.
Causal Consistency
Causal consistency is a more relaxed and often more practical model. It doesn't enforce a total order on all operations, but it does enforce a partial order based on cause and effect. If operation A potentially causes operation B (e.g., you read some data and then write something based on it), then all processes must see A before they see B. Concurrent operations (those with no causal link) can be seen in different orders by different processes.
A classic example is a comment thread: you should never see a reply to a comment before you see the original comment. Causal consistency ensures this.
Consistency Patterns in Distributed Systems | Layrs
The Layrs article provides a concise explanation of causal consistency and its common use cases.
In the "Deep Dive" section, find the paragraph describing the middle-ground models and read about Causal consistency.
This model is a fantastic middle ground. It provides strong enough guarantees to prevent logically confusing scenarios for users, without the high coordination cost of total ordering. We'll explore the mechanisms for tracking causality (like vector clocks) in our next lesson.
Eventual Consistency
Finally, we have eventual consistency, a model you've already put into practice. This model offers the weakest guarantees but provides the highest availability. It promises that if no new updates are made to a given data item, all replicas will eventually converge to the same value. It makes no promises about when this will happen or the order in which updates will be seen.
Distributed Systems 7.3: Eventual consistency
Martin Kleppmann's video on eventual consistency provides a great contrast to linearizability and formally defines the model.
Watch the following segments: The introduction, which recaps the downsides of linearizability. The explanation of the CAP theorem and the fundamental choice it forces. The definitions of eventual and strong eventual consistency.
The great benefit of eventual consistency is that replicas can accept writes locally without waiting for network communication, making write operations extremely fast and highly available. This is why it's the default for many large-scale NoSQL databases like DynamoDB and Cassandra. The challenge, of course, is that concurrent writes can lead to conflicts that must be resolved later. Your implementation of the Saga pattern is a strategy for managing a workflow across services that are, from a system-wide perspective, eventually consistent.
4. Analyzing the Trade-offs
At the senior level, choosing a model is about justifying the trade-offs. Let's explicitly summarize them.
| Model | Guarantees | Pros | Cons | Typical Use Cases |
|---|---|---|---|---|
| Linearizability | All operations appear atomic and ordered by real-time. All reads see the latest completed write. | Simple to reason about (like a single machine). Prevents all stale reads. | High latency for writes. Low availability during network partitions. Often a performance bottleneck. | Financial ledgers, inventory management, unique username allocation. |
| Sequential | All operations appear in the same total order to all observers, respecting per-process order. | Stronger than causal/eventual. Better performance than linearizable. | Violates real-time ordering, which can be non-intuitive. | Multi-core processor memory models, some distributed algorithms. |
| Causal | Preserves the "happens-before" relationship. Concurrent operations can be seen in different orders. | Good balance of user experience and performance. Prevents logical anomalies. | More complex to implement than eventual. Does not prevent all stale reads. | Comment threads, collaborative editing, chat systems. |
| Eventual | If writes stop, replicas will eventually converge. No ordering guarantees. | Highest availability and write throughput. Lowest latency for writes. Tolerant to network partitions. | Stale reads are possible. Requires conflict resolution logic, which is complex for developers. | Social media feeds, view counters, analytics data, DNS. |
In a system design interview, you'll rarely pick one model for the entire system. A robust architecture, like the e-commerce example in the Layrs article, often uses a hybrid approach: strong consistency for payment processing and inventory, and eventual consistency for the product catalog and user recommendations.
Conclusion
In this lesson, we established a formal mental model for reasoning about data consistency. You can now classify the four major models—linearizability, sequential, causal, and eventual—and, most importantly, analyze the critical trade-offs between their guarantees and their impact on system performance and availability.
Key Takeaways:
- Consistency is a spectrum, not a binary choice, with each model offering a different balance of correctness, performance, and availability.
- Linearizability provides the illusion of a single copy of data, ordered by real-time, but at a high cost to latency and availability.
- Sequential consistency relaxes the real-time constraint but maintains a global total order of operations.
- Causal consistency preserves cause-and-effect relationships, offering a practical middle ground for many user-facing applications.
- Eventual consistency prioritizes availability and performance, guaranteeing only that replicas will converge over time, which requires developers to handle stale data and resolve conflicts.
In our next lesson, we will dive into the mechanics of how causal consistency is implemented. We will explore Lamport timestamps and vector clocks, the foundational tools used to establish the causal ordering of events in a distributed system.