Welcome to your second lesson. In our previous session, we established that any collaborative application is a distributed system, and for your goal of building an offline-first tool, a "local-first" architecture is the most effective model. We concluded by identifying the central challenge: how to manage and merge data when multiple users can make changes independently.
Today, we will directly address that challenge by exploring the two fundamental strategies for managing data across replicas: strong consistency and eventual consistency. By the end of this lesson, you will be able to distinguish between these two models, understand the critical trade-offs they represent in terms of performance and user experience, and see why your target application naturally gravitates toward one of them. This is a cornerstone concept that sets the stage for why CRDTs are so powerful.
The Two Poles of Data Synchronization
When a piece of data is replicated across multiple nodes (e.g., servers in a data center, or users' devices), we need a rule—a consistency model—to define what it means for that data to be "correct." Let's explore the two primary approaches.
Strong Consistency: The Single Source of Truth
Strong consistency is the most intuitive model. It guarantees that any read operation will always return the value from the most recently completed write. In effect, the entire distributed system behaves as if it were a single, non-distributed computer. All users see the same data at the same time, always.
This guarantee is crucial for certain types of operations. For example, if a user changes their password, you need to ensure that their very next login attempt uses the new password, not the old one. To understand why this is non-negotiable in some contexts, let's consider a familiar service.
Eventual Consistency vs. Strong Consistency | How to decide between the two in System Design
The video "Eventual Consistency vs. Strong Consistency" provides excellent, practical examples. This first clip explores why a URL shortener requires strong consistency.
Please watch the segment from this clip. The presenter explains that if a user creates a short URL, they expect to be able to use it immediately. If the read operation (redirecting the short URL) doesn't see the result of the write operation (creating the mapping), the service is functionally broken. This negatively impacts reliability and user experience.
As the video demonstrates, the primary benefit of strong consistency is that it's simple to reason about—there are no "stale reads." However, this safety comes at a cost. To guarantee that a write is visible everywhere, the system must coordinate among its replicas. This often involves locking the data and waiting for acknowledgements from a majority of replicas before confirming the write. This coordination takes time, adding latency to every write operation.
Eventual Consistency: Converging Over Time
Eventual consistency takes a different approach. It prioritizes availability and performance over immediate, universal consistency. The model guarantees that if no new updates are made to a given data item, all replicas will eventually converge on the same value. However, it allows for a temporary window of inconsistency where different replicas might return different values.
This is the model that powers many large-scale web services where immediate consistency is not strictly required. The image below provides a simple visual metaphor.
For many features you've likely worked on, this slight delay is perfectly acceptable and often goes unnoticed. The classic example is the "like" count on a social media post.
Eventual Consistency vs. Strong Consistency | How to decide between the two in System Design
We'll return to the same video to see a case where eventual consistency is a pragmatic choice.
Watch the segment from the "likes" example. The key takeaway here is twofold. First, from a user experience perspective, seeing 1000 likes instead of 1001 for a few seconds is not a critical failure. Second, and more importantly for you as an engineer, enforcing strong consistency for a high-concurrency operation like this can be a performance nightmare, leading to database lock contention, transaction retries, and failed requests—ultimately resulting in a worse user experience.
By relaxing the consistency guarantee, the system can process writes much faster. It can accept a write on a local replica immediately and then propagate that change to other replicas in the background, without making the user wait. This is fundamental to enabling the offline-first capabilities you want to build. When a user is offline, they are essentially in a network partition. An eventually consistent system allows them to continue working by writing to their local replica. The system will then sync those changes when the connection is restored.
A Spectrum of Trade-offs
Strong and eventual consistency are not a rigid binary choice but rather the endpoints of a spectrum. The decision of where to land on this spectrum involves a fundamental trade-off between correctness, performance, and availability.
A more formal way to think about this, especially relevant to your experience as a senior engineer architecting systems, is the PACELC theorem. It's an extension of the more famous CAP theorem (which we will cover next lesson) and is often more practical for day-to-day design decisions.
The PACELC framework states:
- If there is a Partition (a network failure), a system must choose between Availability (continuing to operate) and Consistency (stopping to avoid data divergence).
- Else (during normal operation), a system must choose between Latency (being fast) and Consistency (ensuring data is up-to-date).
The following reading provides an excellent overview of this framework and its real-world application.
Testing Distributed Systems Failures with Interactive Simulators
This article provides a powerful framework for understanding the real-world trade-offs in distributed systems. It moves beyond theory to discuss how actual databases are categorized.
Please read the section Part 2: CAP and PACELC. Focus on the distinction it makes between system behavior during a network partition and during normal operation. The key insight is that most of the time, the choice isn't about failure, but about performance: do you prioritize low Latency or strong Consistency? Note the examples of systems like DynamoDB (a PA/EL system choosing latency and availability) versus Google Spanner (a PC/EC system choosing consistency).
For your collaborative, offline-first canvas application:
- When a user goes offline, they are in a network Partition. The app must remain usable, so it must choose Availability.
- When users are collaborating in real-time, low Latency is critical for a good user experience.
This places your application squarely in the PA/EL category, which naturally leads to a model of eventual consistency.
From Eventual to Strong Eventual Consistency
Simply choosing "eventual consistency" is not enough. A naive implementation, such as "the last writer wins" (where the chronologically last update overwrites all others), can lead to data loss. If two offline users edit the same node in your visual workflow, you don't want one user's work to be silently discarded when they come back online.
This is where CRDTs enter the picture. They provide a specific, more robust guarantee called Strong Eventual Consistency (SEC).
Introduction to CRDTs for Realtime Collaboration - DEV Community
This developer-focused blog post gives a concise definition of Strong Eventual Consistency, the property that CRDTs guarantee.
Read the section titled Strong Eventual Consistency. The key guarantee is that "any two nodes that have received the same set of updates will deterministically be in the same state."
The difference is subtle but crucial:
- Eventual Consistency: Replicas will eventually converge to some value, but data might be lost along the way (e.g., last-writer-wins).
- Strong Eventual Consistency: Replicas will eventually converge to the same value, and that value is the result of correctly merging all concurrent updates without conflict or loss.
CRDTs are the data structures designed to provide this guarantee automatically, making them the perfect foundation for your project.
Conclusion
In this lesson, we have dissected the fundamental choice between strong and eventual consistency.
Here are the key takeaways:
- Strong Consistency provides the guarantee that all reads see the most recent write, creating a simple mental model but at the cost of higher latency and lower availability. It is unsuitable for offline-first applications.
- Eventual Consistency prioritizes availability and low latency, guaranteeing that all replicas will converge over time. This is essential for responsive, offline-capable collaborative software.
- The PACELC framework clarifies this trade-off: in normal operation, you must choose between lower Latency or stronger Consistency. Your project requires prioritizing latency.
- Strong Eventual Consistency (SEC) is the specific guarantee provided by CRDTs. It ensures that all concurrent updates are merged predictably, preventing the data loss that can occur in simpler eventually consistent systems.
We've now seen that for a local-first application to work, it must choose Availability during a network partition. In our next lesson, we will formalize this idea by exploring the famous CAP Theorem, which provides the theoretical underpinning for this unavoidable trade-off.