Module 02 · Lesson 08
CAP and PACELC
Partitions are not optional. The real question is what you give up, and only while they last.
What you will be able to do
- State CAP precisely and correct the 'pick two of three' shortcut
- Explain PACELC's latency-versus-consistency trade-off in normal operation
- Map consistency choices to concrete product features
- Justify a database choice using the trade-off rather than the label
What CAP actually says
Consistency here means linearizability: every read sees the most recent write. Availability means every reachable node answers. Partition tolerance means the network can drop messages. Since a network can always drop messages, P is not a choice — so the theorem's real content is narrow and useful: while a partition exists, you can either fail some requests or serve stale data.
The shortcut that misleads
"Pick two of three" implies you might choose to skip partition tolerance. You cannot. The honest restatement is "when the network splits, choose consistency (refuse or block) or availability (serve possibly stale data)."
PACELC: what happens the other 99% of the time
| Situation | Choice | What it costs |
|---|---|---|
| Partition (P) | Availability | Writes on the minority side diverge; reconciliation later |
| Partition (P) | Consistency | Minority side refuses writes; users see errors until the partition heals |
| Normal (E) | Latency | Replicas answer locally without coordinating; reads may be a few hundred ms stale |
| Normal (E) | Consistency | Reads wait for quorum or leader confirmation; extra network round trip per operation |
Most of the engineering value is in the E branch. Every quorum read is a deliberate latency payment; every locally-served read is a deliberate staleness payment. Products are made of both: a bank balance must coordinate, a follower count need not.
Turning it into a design statement
Name the operation, not the database
"Marking a message read" and "transferring money" can live in the same product with different consistency, and often should.
Say which way you lean and why
"For the like counter I take stale reads and eventual convergence, because being 3 seconds behind cannot hurt anyone and the write volume is enormous."
Quantify the staleness
"Replication lag is typically under 200 ms; if a user must see their own update, I read their own writes from the primary for a few seconds after they write." That is the practical fix for most read-your-writes complaints.
Handle the conflict rather than pretending it does not exist
If both sides can write during a partition, decide the merge: last-write-wins with timestamps, per-field merge, or a CRDT. Naming the merge rule is what makes eventual consistency a design instead of a hope.
Q. Which database should I pick, a CP or an AP one?
Ask per dataset, not per product. You usually end up with a strongly consistent store for money, inventory and identity, and an eventually consistent store for feeds, counters, analytics and search indexes. Naming that split is a stronger answer than a vendor name.
Worth remembering
- Partition tolerance is not optional for a distributed system, so CAP really means: during a partition, choose consistency or availability.
- PACELC: if Partition, A or C; Else, Latency or Consistency. The 'else' affects you every day.
- Strong consistency means coordinating between replicas, which costs latency and availability on the minority side.
- Choose per feature: a payment intent may need consistency; a like counter does not.
Checkpoint
Answer all 2 questions to finish the lesson.
1. Why is 'pick two of three' a misleading summary of CAP?
Networks partition, so partition tolerance is a given. The theorem's practical content is the trade-off between refusing requests and serving stale data while the partition lasts.
2. What does the 'ELC' part of PACELC cover?
Else (no partition), choose Latency or Consistency. This is the everyday trade-off: coordinating replicas costs milliseconds, skipping coordination costs freshness.