Strong vs Eventual Consistency

Strong Consistency

A system is strongly consistent when a finished write is visible to every later read. It does not matter which client reads or which replica answers.

The mechanism is simple. The write goes to the primary, the one node that accepts writes. The primary sends the change to its replicas. It does not confirm the write until enough replicas report that they have it. Only then does the client hear "OK". This is synchronous replication: the write waits for the copying to happen.

No replica is behind at the moment the write completes. So no read can return old data.

What it gives you.

• Reads are always correct. No user ever sees an old value.
• Simple application code. You never handle a stale read, meaning a read that returns an older value.

What it costs you.

• Slow writes. The write waits for the slowest replica it needs, plus the network. Replicas in the same data centre add about a millisecond. A replica on another continent adds the full round trip. No engineering removes that delay, because it comes from the distance itself.
• Refused writes. If a needed replica is unreachable, the system faces a choice. Accept the write and break the promise, or refuse the write. A strongly consistent system refuses.

The classic case for it is money. You withdraw 100 from an account holding 500. Every later read, anywhere, must say 400. A window where some machine still says 500 is a window where the money can be spent twice.

Refusing writes is correct behaviour for a bank balance. It is terrible behaviour for a photo feed. That difference is why this is a decision, not a default.

Eventual Consistency

A system is eventually consistent when its copies converge once writes stop. Converge means they all end up holding the same value. The promise is convergence, not timing.

The mechanism is the same replication with the waiting removed. The write goes to one node. That node confirms it at once. The change travels to the other replicas in the background. This is asynchronous replication: the copying happens after the confirmation. A read that reaches a replica before the change does returns the old value.

What it gives you.

• Fast writes. A write is as fast as one machine.
• Availability. The system keeps accepting reads and writes while replicas are unreachable, because no node waits on another.

What it costs you.

• A stale window. For a short time, two users can see different data.
• Careful application code. Every reader must behave correctly when a value is briefly old.

DNS, the system that maps domain names to server addresses, works this way. Change a domain's address, and some resolvers serve the old address for minutes or hours. Nobody calls DNS broken. The staleness is known, measured, 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 the trade is acceptable, and most explanations skip it.

Inside one data centre, lag is normally a few milliseconds. Across regions, it is tens to low hundreds of milliseconds. For most data, the window closes before the user can even reload the page.

The window is not always small. Lag grows under heavy write load, while a restarted replica catches up, and when a network link degrades. A replica can fall minutes behind. If lag affects correctness anywhere in your design, monitor it, and say that in the interview.

Read Your Own Writes

Here is the practical middle ground, and the reason eventual consistency is usable at all.

Users rarely notice that other people see stale data. They notice when they see it themselves. You post a comment, the page refreshes, and your comment is missing. The system is working exactly as designed, and it still looks like a bug.

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

You keep cheap replica reads for almost all traffic. You remove the one staleness a user can actually see. The cost is a small piece of routing logic and slightly more load on the primary.

Two more named levels sit between the extremes. Causal consistency keeps dependent operations in order, so a reply never appears before the message it answers. Bounded staleness puts a hard limit on how old a read may be, in seconds or in versions. Some stores, including Azure Cosmos DB and MongoDB, let you pick a level per operation.

One Page, Several Answers

The common mistake is choosing one model for a whole system. Real designs choose per piece of data.

Look at one shopping page. The account balance must be strong, because a wrong number is a real problem. The stock count should be strong too, since selling the last item twice costs money. The view counter can be eventual, because nobody notices a few seconds of delay there. The recommendations can be minutes old.

That is four answers on one page. Name the data, not the system. "Balance reads go to the primary and are strong. Everything else is served from replicas."

Comparing the Two

Treat the two models as the ends of a range, not as two boxes. Most real systems sit between the ends, on purpose.

Choosing

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

Three glossary lessons hold the theory behind this choice. CAP Theorem explains the forced choice during a network partition, a failure that cuts machines off from each other. PACELC Theorem extends it to normal operation, where every request trades latency against consistency. Quorum is the tuning tool: it sets how many replicas must confirm each read and write. And how the writing nodes themselves are arranged is its own trade-off, covered in Primary-Replica vs Peer-to-Peer Replication.

💡 In the interview: do not answer "strong" or "eventual" for the whole system. Split it. Name the one or two pieces of data that cannot be stale, and send those reads to the primary. Put everything else on replicas. Then add read-your-own-writes for each user's own data, because that is the only staleness a user can see. Expect the follow-up "how stale can a replica get?". Answer with numbers: a few milliseconds inside a data centre, and minutes when a replica is catching up, which is why lag is monitored.

Key takeaway: strong consistency promises that every read returns the newest write. The cost is writes that wait for replicas, and writes that are refused when replicas are unreachable. Eventual consistency confirms at once and lets the copies converge in the background. The gain is speed and availability, and the cost is a short window where two readers can disagree. Neither is better. Decide per piece of data, add read-your-own-writes so users always see their own changes, and know your replication lag.