Strong vs Eventual Consistency

What a read may return after a write when data is copied to several machines: the models from linearizable to eventual, how systems provide each one, and how eventually consistent stores settle conflicts.

Overview

When a database keeps copies of the same data on several machines, called replicas, a write reaches them one at a time. For a short while some replicas have the new value and some still have the old one. A consistency model is the promise the database makes about that window: what a read is allowed to return while the copies catch up.

Strong consistency usually means linearizability: the system behaves as if there were only one copy, so a read never returns a value older than a write that has already finished. Eventual consistency promises much less: if writes stop, the replicas end up the same. Between the two sit several useful guarantees, such as causal consistency and read-your-writes, that fix the anomalies users notice most, at a fraction of the cost.

The choice matters because the strong end costs time on every request and some availability during failures, while the weak end moves work into your application code. Good designs choose a model for each feature, not one for the whole system.

The Fundamentals chapter introduced these words, and this chapter goes deeper: the exact promise of each model, the anomalies drawn on a timeline, the mechanisms that provide each guarantee, and how eventually consistent stores settle conflicting writes. The CAP theorem has its own chapter (CAP & PACELC Deep Dive), and so does the math of read and write quorums (Quorum Consensus); this chapter points to them where they matter.

What you will be able to do

  • Place linearizable, sequential, causal, the four session guarantees and eventual consistency on one ladder, and say what each allows.
  • Draw the three common anomalies (a stale read, your own write missing, going back in time) and name the guarantee that prevents each one.
  • Explain how a system provides each guarantee: a single leader, synchronous or asynchronous replication, quorum reads, sticky routing and version tokens.
  • Explain how last-write-wins loses data, and what version vectors and CRDTs do instead.
  • Choose a model for each feature and say what it costs in latency and availability.

Key concepts

  • Linearizability
  • Sequential consistency
  • Causal consistency
  • Session guarantees
  • Eventual consistency
  • Replication lag
  • Version tokens
  • Last-write-wins
  • Version vectors
  • CRDTs

Interview questions

  • What is the difference between strong and eventual consistency?
  • What is linearizability, and how does it differ from sequential consistency and from serializability?
  • A user edits their profile, reloads the page, and sees the old version. What is happening, and how do you fix it?
  • What are the four session guarantees? Give an anomaly that each one prevents.
  • What is causal consistency, and why is it called the strongest model an always-available system can offer?
  • How does last-write-wins lose data, and what would you use instead?
  • How do version vectors detect a conflict, and what happens after one is found?
  • Choose a consistency model for each part of an online store.
  • Is Amazon S3 strongly consistent? Is DynamoDB?
  • How can asynchronous replication lose a write that the client was told had succeeded?

Sign up free to read the full topic

More System Design topics

Start free on Cariara · Coding problems · System design studio