Art of Codeartofcode
Lesson 2 of 17

16. Consistency and CAP

1
The picture to keep in your head
2
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 breaks
13
Practice: five levels
14
Interview questions
15
Solutions
16
Sources
17
Code lab
16. Consistency and CAP

16.1 What does "consistent" actually mean?

3 min read+10 XP

Consistency models

At the bank: "The books are consistent" can mean two different things. The accountant means "the rules hold": money in equals money out, no negative balances. The customer means "both counters tell me the same balance".

In the system: The word is used for two separate ideas, and mixing them up causes endless confusion:

  1. The C in ACID (Chapter 8): a transaction leaves the database obeying its rules: constraints, foreign keys, "stock can't go below zero". It's about one database keeping its own data valid.
  2. The C in CAP (and in "consistency models"): every copy gives the same, latest answer. It's about how replicas agree with each other.

This chapter is about the second meaning. A consistency model is a promise about what reads can return when data is copied across machines: always the latest value? Possibly an older one? Never an older one than you've already seen?

Memory code: "ACID's C keeps the rules; CAP's C keeps the copies agreeing."