CAP Theorem & Consistency Models
CAP Theorem
A distributed system, during a network partition, can only guarantee two of three:
- Consistency — every read returns the most recent write
- Availability — every request gets a (non-error) response
- Partition tolerance — the system keeps working despite network splits
flowchart TD
P["Network Partition Occurs<br/>Node 1 has data v2, Node 2 has data v1<br/>they cannot sync"]
P --> CA["Choose Consistency<br/>Node 2 returns an ERROR<br/>rather than stale data v1"]
P --> CB["Choose Availability<br/>Node 2 returns stale v1<br/>rather than an error"]
CA --> CAEx["Example: banking,<br/>payment ledgers"]
CB --> CBEx["Example: social feeds,<br/>product catalogs"]
The practical framing: partition tolerance isn't really optional in a real distributed system (networks will partition) — so the live decision is CP vs AP, made at the moment of partition, not a permanent architectural label.
PACELC — the sharper, more-often-relevant extension
CAP only governs behavior during a partition — but partitions are rare; most of the time the system runs normally, and CAP says nothing about that case. PACELC fills the gap:
Partition → choose A or C; Else (normal operation) → choose Latency or Consistency.
This is the better interview answer: most of the time you're choosing between waiting for all replicas to confirm a write (consistency, higher latency) versus acknowledging fast from one replica and syncing after (lower latency, eventual consistency). DynamoDB and Cassandra are PA/EL (available during partition, low-latency normally). MongoDB (majority writes) and traditional RDBMS replication lean PC/EC.
Consistency Models — a spectrum, not a binary
| Model | Guarantee | Cost | Example use |
|---|---|---|---|
| Strong | Every read sees the latest write, globally | Highest latency (coordination on every write) | Bank balance, inventory count |
| Eventual | Replicas converge eventually, reads may be stale meanwhile | Lowest latency | Social media like counts, DNS |
| Causal | Causally related writes seen in order (a reply never appears before the comment it replies to) | Middle ground | Comment threads, chat |
| Read-your-writes | A user always sees their own writes immediately, even if others see them later | Cheap (route a user's reads to the replica that took their write) | Profile updates |
Interview Drills
- A system is CP during a partition. What does the user experience? — Some requests return errors or time out rather than risk returning stale data; the system sacrifices availability to guarantee every successful read reflects the latest write.
- When would you deliberately choose eventual consistency over strong, and how do you justify it? — Whenever the coordination-latency cost of strong consistency isn't worth it for the domain — a "like" counter off by a few for a second causes no harm; paying millisecond coordination on every write to keep it exact isn't justified. Justify with the concrete cost/benefit, not just "eventual consistency is fine here."
- Why does PACELC matter more day-to-day than CAP? — Because partitions are rare events but the latency/consistency trade-off is live on every single write, all the time.
Cross-links
[[Core Vocabulary & Quality Pillars]] · [[Database Replication & Sharding]] · [[SD Interview Framework & Pitfalls]]