16. Consistency and CAP
1
The picture to keep in your head2
16.1 What does "consistent" actually mean?3
16.2 What is strong consistency?4
16.3 What is eventual consistency?5
16.4 What are read-your-writes and monotonic reads?6
16.5 What is a network partition?7
16.6 What does the CAP theorem actually say?8
16.7 What do CP and AP systems look like in practice?9
16.8 What is PACELC?10
16.9 How do quorums give tunable consistency?11
16.10 How do you choose consistency for each feature?12
Memory card and where the analogy breaks13
Practice: five levels14
Interview questions15
Solutions16
Sources17
Code lab16. Consistency and CAP
16.4 What are read-your-writes and monotonic reads?
3 min read+10 XP
At the bank: Between "one ledger" and "couriers whenever", there are useful promises to one customer: "after you deposit, you'll always see it" and "once you've seen a balance, you'll never be shown an older one".
In the system: These are session guarantees, weaker than strong consistency but much cheaper, and they fix the bugs users actually notice (Chapter 14, section 14.5):
| Guarantee | Promise | Typical fix |
|---|---|---|
| Read-your-writes | You always see your own writes | Read from the leader for a while after you write, or wait for the replica to reach your write's log position |
| Monotonic reads | You never see data go backwards | Keep each user on the same replica |
| Monotonic writes | Your writes are applied in the order you made them | Send a user's writes through one leader or sequence them |
| Causal consistency | If B was caused by A (a reply to a comment), everyone who sees B also sees A | Track dependencies; deliver in order |
Causal consistency deserves a mention: it's one of the strongest models that can still stay available during partitions, and it's exactly what comment threads and chats need: nobody should see a reply before the message it answers.
Memory code: "Show me my own deposit, never go back in time, and never show the answer before the question."