Module 13 / Replication

Module 13 · lesson 9 of 9 · Read 9 min

Consistency models

Linearizable, causal, eventual, and CAP without the slogans.

What you'll learn

  1. One order, four observers
  2. Linearizable: behaves like one copy
  3. Eventual: they'll agree, someday
  4. In between: guarantees for one user
  5. Causal: causes before effects, for everyone
  6. CAP, without the slogans
  7. Choose per feature, not per system

Throughout this module, copies of data have disagreed for a while: followers lag, leaders conflict, quorum reads catch writes halfway. "Is the system consistent?" turns out to be the wrong question. The useful question is: what exactly can a reader see while copies disagree?

The answer to that is a consistency model. It's a contract between the database and your code: a list of things that can and can't happen. Stronger contracts are easier to program against and more expensive to provide. This lesson walks through the ones you'll actually meet, from strongest to weakest, and ends with an honest version of the CAP theorem.

A consistency model is a promise about which values a read may return, given the writes that have happened. Stronger models rule out more surprises and cost more coordination.

One order, four observers

Use one Tiffin order as the running example. Its status changes from accepted to picked_up when the rider collects it. Four people are looking at it: the customer, the restaurant, a support agent, and the rider. Each reads from whichever replica their request reaches.

What could go wrong while the change replicates?

  • The rider taps "picked up", refreshes, and sees accepted again.
  • The customer sees picked_up, refreshes, and sees accepted.
  • The support agent sees picked_up while the customer, at the same moment, still sees accepted.
  • The customer gets a "your rider is nearby" notification for an order still shown as accepted.

Each consistency model rules out some of these and allows others.