Strong vs Eventual Consistency

What Eventual Consistency Gives You

• Fast writes. A write only needs one machine to confirm it.
• Better availability. The system keeps accepting reads and writes while some replicas are unreachable, because no node waits for another.

What Eventual Consistency Costs You

• A stale window. For a short time, updates are still spreading, so two users may briefly see different data.
• More careful application code. The application must behave correctly when a value is briefly old.

The Domain Name System (DNS), which maps domain names to server addresses, works this way. When a domain's address changes, some DNS servers keep returning the old address for minutes or hours. Nobody calls DNS broken, because the delay is known and planned for.

How Long Is "Eventually"?

Replication lag is the delay between a write on one node and its arrival at the other copies. This number decides whether eventual consistency is acceptable.

• Inside one data center, lag is usually a few milliseconds.
• Across regions, lag is usually tens to a few hundred milliseconds.

For most data, the stale window ends before a user can even reload the page. But lag is not always small. It grows under heavy write load, when a restarted replica is catching up, or when a network link is slow. A replica can fall minutes behind. If lag affects correctness anywhere in your design, monitor it.

Read Your Own Writes

Users rarely notice when other people see slightly old data. They notice when they see it themselves. For example, you post a comment, the page refreshes, and your comment is missing. The system works exactly as designed, but it looks like a bug.

The fix is small. For a short time after a user writes, send that user's reads to the primary. Everyone else keeps reading from replicas. This is called read-your-own-writes consistency.

Almost all traffic still uses the cheaper replica reads. And the one kind of staleness that users actually notice is removed. The cost is a small amount of routing logic, and slightly more load on the primary.

There are also levels between the two extremes:

• Causal consistency keeps related operations in order. For example, a reply never appears before the message it answers.
• Bounded staleness sets a limit on how old a read may be, for example 5 seconds.

Some databases, like Azure Cosmos DB and MongoDB, let you choose a consistency level for each operation.

One Page, Several Answers

A common mistake is choosing one consistency model for a whole system. Real designs choose for each piece of data.

Look at a single shopping page:

• The account balance should be strongly consistent, because a wrong number is a real problem.
• The stock count should be strongly consistent at checkout, because selling the last item twice costs money.
• The view counter can be eventually consistent, because nobody notices a few seconds of delay.
• The recommendations can be minutes old.

That is several answers on one page. So name the data, not the system. For example: "Balance reads go to the primary and are strongly consistent. Everything else is served from replicas."

Strong vs. Eventual Consistency

Think of the two models as the two ends of a range. Most real systems sit somewhere between them, on purpose.

Choosing Between Them

• The data counts something that must be exact, like money, stock, seats, or bookings: choose strong consistency.
• The data is content or a casual count, like feeds, likes, views, or recommendations: choose eventual consistency.
• Users read back their own changes: choose eventual consistency, plus read-your-own-writes.
• Replicas are in several regions, and writes must stay fast: choose eventual consistency, because strong consistency waits for the round trip on every write.
• You cannot decide yet: start with strong consistency, and relax specific reads when measurements show the need.

Three other lessons explain the theory behind this choice. The CAP Theorem lesson explains the choice during a network partition, which is a failure that cuts machines off from each other. The PACELC Theorem lesson extends it to normal operation, where requests trade latency against consistency. The Quorum lesson explains how many replicas must confirm each read and write.

Using This in an Interview

Do not answer "strong" or "eventual" for the whole system. Split the answer. Name the one or two pieces of data that must never be stale, and send those reads to the primary. Serve everything else from replicas. Then add read-your-own-writes for each user's own data, because that is the staleness users notice.

A common follow-up question is: "How stale can a replica get?" Answer with numbers: usually a few milliseconds inside a data center, but possibly minutes while a replica is catching up. That is why replication lag is monitored.

Key Takeaways

• Strong consistency promises that every read returns the newest write. Writes wait for replicas, and may be refused when too many replicas are unreachable.
• Across distant data centers, strong consistency increases write latency, because synchronous replication must cross the distance.
• A quorum is the minimum number of servers that must complete an operation. With 5 replicas, a majority quorum is 3.
• Eventual consistency confirms writes immediately. Updates spread over time, and readers may briefly see different data.
• If no new updates are made, all copies in an eventually consistent system become identical.
• Read-your-own-writes removes the staleness users notice most.
• Choose a consistency level for each piece of data, not for the whole system.

Consistency decides what readers see after a write. The next lesson, Primary-Replica vs Peer-to-Peer Replication, looks at how the machines that hold the copies are organized.

Practice Questions

Try each question first, then open the answer.

1. A database uses strong consistency, with replicas in Virginia and Frankfurt. A write in Virginia takes 5 ms locally, and each write must wait for Frankfurt to confirm. A round trip between the two takes about 90 ms. About how long does each write take, and why?

<details> <summary>Show answer</summary>

About 95 ms. The local work takes 5 ms, and waiting for Frankfurt adds a round trip of about 90 ms. This is synchronous replication: the write is not confirmed until the distant replica has it. Faster servers cannot remove the 90 ms, because it comes from the distance between the data centers.

</details>

2. A system has 5 replicas and uses a majority quorum for writes. How many replicas must confirm each write? Can the system still accept writes with 2 replicas down? With 3 replicas down?

<details> <summary>Show answer</summary>

3 replicas must confirm each write. A majority of 5 is 3. With 2 replicas down, 3 are still running, so writes can still succeed. With 3 replicas down, only 2 are running, which is less than the quorum of 3. So the system refuses writes, to keep its consistency promise.

</details>

3. A system has 5 replicas. Writes need 3 confirmations, and reads ask 3 replicas. Why does every read see the latest write? What changes if reads ask only 2 replicas?

<details> <summary>Show answer</summary>

3 + 3 = 6, which is more than 5, so the groups always overlap. At least one of the 3 replicas that answer a read must also be one of the 3 that confirmed the write. So the read finds the latest value. If reads ask only 2 replicas, 3 + 2 = 5, which is not more than 5. The 2 replicas that answer a read could both be the ones that missed the write, so the read may return an old value.

</details>

4. A user posts a comment and refreshes the page 50 ms later. The read goes to a replica, and replication lag is about 200 ms. What does the user see, and how can the design fix it?

<details> <summary>Show answer</summary>

The comment is missing, because the replica has not received it yet. The system is eventually consistent, and the user read inside the stale window. The fix is read-your-own-writes. For a short time after a user writes, send that user's reads to the primary. Other users can keep reading from replicas, and will see the comment a moment later.

</details>

5. A shopping page shows an account balance, a product's stock count, the product's view count, and recommendations. Which of these need strong consistency?

<details> <summary>Show answer</summary>

The account balance and the stock count. A wrong balance is a real problem, and a wrong stock count at checkout can sell the last item twice. The view count and the recommendations can be eventually consistent, because a short delay does no harm. So the design sends balance and stock reads to the primary, and serves the rest from replicas.

</details>