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.9 How do quorums give tunable consistency?
3 min read+10 XP
In practice
At the bank: With three counters, a rule: a withdrawal counts once two counters record it, and a balance check asks two counters and believes the newer figure. Because any two counters out of three share at least one, you always see the latest withdrawal.
In the system: Leaderless stores (Chapter 14, section 14.10) let you tune consistency per request with N, W and R:
- W + R > N (for example N = 3, W = 2, R = 2): read and write sets overlap, so reads usually see the latest write. Good for the wallet balance, at the cost of waiting for two replicas each time.
- W + R ≤ N (for example W = 1, R = 1): fastest and most available, but reads may be stale. Fine for view counts.
Two cautions:
- Quorums alone don't make a system linearizable. Concurrent writes, writes that partly succeed then fail, and "sloppy" quorums can still produce surprising reads. Systems that need true linearizability use consensus, or extra steps like read repair before returning.
- Quorum size sets fault tolerance. With N = 5, W = 3 and R = 3, you can lose 2 replicas and still read and write consistently; with W = 5, losing one replica blocks all writes.
Memory code: "Ask enough counters that the asking and the telling must overlap."