Understanding Strong vs. Eventual Consistency

Balancing the trade-offs between strict correctness and high-speed replication in distributed systems

In the world of distributed databases and systems, Read Consistency is one of the most critical—and often misunderstood—concepts. It defines what a user sees when they request data, particularly while that data is being updated or replicated across multiple servers.

Eventual Consistency

Here is a detailed breakdown of consistency models, ranging from the strictest guarantees to the loosest, and how replication strategies impact what you read.

---

1. The Core Dilemma: Latency vs. Correctness

At the heart of consistency is a trade-off. In a perfect world, every read would return the absolute latest data immediately. However, data takes time to travel between servers (replication).

• If you want strict correctness: You must wait for data to be copied to all replicas before allowing a read. This increases latency (slowness).

• If you want speed (low latency): You allow reads from any replica immediately, even if that replica hasn’t received the latest update yet. This risks showing stale data.

---

2. Strong Consistency

Strong consistency guarantees that once a write is confirmed, any subsequent read—by any client, anywhere in the system—will return that new value.

How it works (Synchronous Replication)

To achieve this, systems typically use Synchronous Replication. When a client writes data:

1. The primary server receives the write.

2. It halts and sends the data to all (or a quorum of) replicas.

3. It waits for those replicas to acknowledge they have saved the data.

4. Only then does the primary tell the client “Write Successful.”

The User Experience

• The Promise: If you deposit $100 and refresh the page instantly, you will always see the new balance.

• The Trade-off: Writes are slower because they move at the speed of the slowest necessary replica. If a network partition occurs (replicas can’t talk to each other), the system often chooses to stop accepting writes to prevent inconsistency (sacrificing Availability for Consistency, as per the CAP theorem).

Strong Consistency

---

3. Weak & Eventual Consistency

Weak consistency models relax the rules. After a write, the system does not guarantee that the next read will see the change.

Eventual Consistency

This is the most common form of weak consistency in modern web-scale applications (like DNS or social media feeds). The system guarantees that if no new updates are made to a given data item, eventually all accesses to that item will return the last updated value.

How it works (Asynchronous Replication)

This relies on Asynchronous Replication:

1. The primary server receives the write.

2. It immediately tells the client “Write Successful.”

3. In the background, it sends the data to the replicas.

The User Experience

• The Promise: The system is incredibly fast and highly available. You can almost always write data, even if parts of the network are broken.

• The Trade-off: Stale Reads. You might update your profile picture, refresh the page, and still see the old picture because your read request hit a replica that hasn’t received the background update yet.

Eventual Consistency

𝐋𝐞𝐚𝐫𝐧 𝐭𝐨 𝐛𝐮𝐢𝐥𝐝 𝐆𝐢𝐭, 𝐃𝐨𝐜𝐤𝐞𝐫, 𝐑𝐞𝐝𝐢𝐬, 𝐇𝐓𝐓𝐏 𝐬𝐞𝐫𝐯𝐞𝐫𝐬, 𝐚𝐧𝐝 𝐜𝐨𝐦𝐩𝐢𝐥𝐞𝐫𝐬, 𝐟𝐫𝐨𝐦 𝐬𝐜𝐫𝐚𝐭𝐜𝐡. Get 40% OFF CodeCrafters: https://app.codecrafters.io/join?via=the-coding-gopher

---

4. Client-Centric Consistency Models

Between “Strong” and “Eventual,” there is a middle ground. These models focus on the experience of a single user rather than the global state of the database.

A. Read-Your-Writes (Session Consistency)

This guarantees that if Client A writes data, Client A will immediately see that update. However, Client B might still see the old data for a while.

• Use Case: Posting a comment on a social media thread. You need to see your comment appear instantly to know it worked. It doesn’t matter if your friend sees it 5 seconds later.

B. Monotonic Reads

This guarantees that if a client reads a value, any subsequent reads by that same client will never return an older value.

• The Scenario: Without this, you might refresh a page and see “ 5 Comments,” then refresh again and hit a lagging replica that shows “3 Comments.” Monotonic reads prevent this “going backward in time” experience.

C. Causal Consistency

This ensures that operations that are causally related are seen by every node in the same order. Unrelated (concurrent) operations can be seen in any order.

• The Scenario: If User A posts a question, and User B replies to it, everyone must see the question before the reply. It would make no sense to see the answer to a question that doesn’t exist yet.

---

5. Summary: The Consistency Hierarchy

The Impact of Async Replication

It is vital to understand that Asynchronous Replication is the root cause of read inconsistency.

When you decouple the “Write Confirmation” from the “Replication Process,” you introduce a Replication Lag. This lag is usually milliseconds, but during high load or network issues, it can spike to seconds or minutes.

• The “Split Brain” Risk: If the primary node crashes before it asynchronously sends writes to the replicas, and a replica is promoted to be the new primary, data loss occurs. The writes that were acknowledged to the client but never made it to the replicas are gone forever.