CAP Theorem and Consistency Models
System Design & ArchitectureLesson 5 of 65 min read
What you'll learn
- State the CAP theorem correctly and explain what a network partition is
- Decide whether a feature should favour consistency or availability during a partition
- Compare strong, causal, read-your-writes and eventual consistency
- Use the quorum rule R + W > N to tune a replicated system
On this page
Two people book the last seat on a flight at the same instant, from two different data centers that cannot talk to each other. Should both bookings succeed, one fail, or the whole site stop accepting bookings until the link is restored? That uncomfortable choice is what the CAP theorem is about.
What CAP actually says
A distributed system keeps copies of data on multiple nodes. The CAP theorem names three properties: Consistency (every read sees the most recent write, as if there were one copy), Availability (every request to a working node gets a non-error response) and Partition tolerance (the system keeps operating even when the network drops or delays messages between nodes).
The common slogan "pick two of three" is misleading. Network partitions happen in any real distributed system, so you cannot opt out of partition tolerance. The real statement is: when a partition occurs, you must choose between consistency and availability. When the network is healthy, you can have both.
Data center A Data center B
+-------------+ +-------------+
| Node 1 |---- X ---| Node 2 |
| x = 5 | link cut | x = 5 |
+-------------+ +-------------+
^ ^
Client 1: write x=9 Client 2: read x
Option CP: Node 2 refuses or errors (consistent,
but not available)
Option AP: Node 2 answers x=5 (available, but
stale until the link heals)CP vs AP in practice
A CP system gives up availability during a partition: it refuses requests that it cannot answer correctly. An AP system stays available and accepts that replicas may diverge, then reconciles later. Which is right depends on the cost of being wrong.
| Feature | Leans | Why |
|---|---|---|
| Bank transfer or payment ledger | CP | A wrong or double-applied balance is worse than a brief error message |
| Seat or inventory reservation | CP | Overselling the last item causes real-world cleanup |
| Leader election, locks and configuration | CP | Two leaders at once is dangerous |
| Social feed, likes, view counters | AP | Showing a slightly stale count is harmless |
| Shopping cart (add items) | AP | Better to accept the add and merge later than refuse it |
| DNS records | AP | Stale answers are acceptable and the system must always respond |
Real products are often described as CP or AP, for example coordination services like ZooKeeper and etcd as CP, and Dynamo-style stores like Cassandra as AP by default. Treat these labels as typical tendencies: most modern databases let you tune the behaviour per query or per cluster, so the honest answer is usually "it depends on the configuration".
Consistency models
"Consistency" is a spectrum, and choosing the weakest model that is still correct for a feature makes systems faster and more available.
| Model | Guarantee | Example of user experience |
|---|---|---|
| Strong (linearizable) | Every read returns the latest committed write, as if one copy existed | After paying, every device shows the order as paid |
| Read-your-writes | You always see your own updates | After editing your profile, you see the edit even if others lag |
| Causal | Effects are never seen before their causes | A reply never appears before the comment it answers |
| Eventual | If writes stop, all replicas converge to the same value | A like count may differ between users for a few seconds |
Strong consistency is the easiest to reason about but costs latency and availability, because replicas must coordinate. Eventual consistency is fast and available but pushes work onto the application: you must handle stale reads and conflicting writes (for example last-write-wins, or merging values).
Quorums: tuning the trade-off
Many replicated stores let you choose, per operation, how many replicas must respond. With N replicas, a write waits for W acknowledgements and a read queries R replicas. If R + W > N, every read set overlaps every write set in at least one replica, so a read is guaranteed to include the latest acknowledged write.
Write x=9 (needs 2 acks)
|
+--------+---------+
v v v
+------+ +------+ +------+
| Rep1 | | Rep2 | | Rep3 |
| x=9 | | x=9 | | x=5 | (not yet updated)
+------+ +------+ +------+
^ ^
+------ Read x ----+ asks 2 replicas
Replies: 9 and 5 -> newest version wins -> 9
R + W = 4 > N = 3, so the read set must include
at least one replica holding the latest write.| N | W | R | R + W > N? | Effect |
|---|---|---|---|---|
| 3 | 2 | 2 | Yes | Balanced; tolerates 1 failed node for reads and writes |
| 3 | 3 | 1 | Yes | Fast reads, slow writes, writes fail if any node is down |
| 3 | 1 | 3 | Yes | Fast writes, slow reads |
| 3 | 1 | 1 | No | Fastest, but reads may be stale (eventual consistency) |
Quorum overlap is not a magic bullet: concurrent writes, clock skew and failed partial writes still need handling, using version numbers or vector clocks and background repair. But the idea is a handy way to explain how a system can tune between speed and freshness.
Common mistakes
- Saying "we will pick CA". Symptom: the design silently assumes the network never partitions. In a distributed system it will, so say what happens when it does.
- Using eventual consistency for money or stock. Symptom: double spends, oversold inventory, and reconciliation tickets.
- Using strong consistency everywhere. Symptom: unnecessary latency and outages from coordination, for data like view counts that did not need it.
- Not handling conflicts. With multiple writable replicas, two writes to the same key will collide. Decide on last-write-wins, merge or reject before the incident, not after.
- Ignoring the user experience of staleness. Symptom: users edit a record, refresh and see the old value. Use read-your-writes for such flows.
How this shows up in interviews and real projects
A strong interview answer does not recite the theorem. It picks a feature, says what the cost of a stale or refused response is, and chooses accordingly: "payments are CP, the activity feed is AP". In real projects the question is usually one of tuning: which operations need a quorum or a leader read, and which can read from any replica. If you are preparing, work through examples in the system design interview prep guide, and revisit replication in the database lesson.
Try it yourself
For an online store, classify each of these as needing strong or eventual consistency and CP or AP behaviour during a partition: payment status, items in a cart, product review count, last unit of stock, and the user's delivery address after editing it. Then pick N, W and R for the stock counter and justify them.
Show a hint
Payment and last-unit stock need strong consistency (CP). Review count can be eventual (AP). Delivery address needs at least read-your-writes. For stock try N = 3, W = 2, R = 2 so R + W > N.
Key takeaways
- During a network partition you must choose between consistency (refuse or error) and availability (answer, possibly stale); partitions cannot be ruled out.
- Choose per feature: money, inventory and locks lean CP; feeds, counters and carts lean AP.
- Consistency is a spectrum: strong, causal, read-your-writes and eventual, each with different cost and UX.
- With N replicas, R + W > N makes reads overlap the latest acknowledged write; lowering R or W trades freshness for speed.
Test yourself
A trick from this lesson's ride: Partitions are weather, not a choice: when it rains, pick consistency or availability. Four more tricks like it wait along the route, each followed by a question.
Frequently asked questions
What is the CAP theorem in simple terms?
It says that when a network partition splits a distributed system, you can keep either consistency or availability, but not both. Consistency means reads see the latest write; availability means every working node responds. Partitions are unavoidable, so the real choice is what to sacrifice when one happens.
What is the difference between strong and eventual consistency?
With strong consistency every read returns the most recent committed write, as though there were a single copy of the data. With eventual consistency replicas may temporarily return different values, but they converge if no new writes arrive. Strong is simpler to reason about, while eventual is faster and more available.
What does R + W > N mean in a quorum system?
N is the number of replicas, W is how many must acknowledge a write and R is how many are consulted on a read. If R + W is greater than N, any read set and write set share at least one replica, so a read includes the latest acknowledged write. It does not fix every concurrency problem, but it is the basis for tunable consistency.