"Available or consistent?" is the question behind half of all deep dives. This unit gives you the precise vocabulary so you choose deliberately instead of hand-waving.
⏱ 30 minPrereq: Units 03–04You'll be able to: justify a consistency model per feature
By the end of this unit
State CAP correctly — and why the choice is really C vs A during a partition.
Distinguish strong, eventual, causal, and read-your-writes consistency.
Apply PACELC: the latency-vs-consistency tradeoff even when nothing is broken.
Pick CP vs AP per feature, with examples, in interview language.
CAP, stated precisely
In a distributed system you want three things: Consistency (every read sees the latest write), Availability (every request gets a non-error response), and Partition tolerance (the system keeps working when the network between nodes drops messages). Networks will partition, so P is not optional. CAP's real content:
The honest version of CAP
"Partitions happen, so the real choice is: when nodes can't talk to each other, do I refuse some requests to stay consistent (CP), or answer with possibly-stale data to stay available (AP)?" Saying it this way shows you understand CAP isn't "pick 2 of 3" trivia.
CP — choose consistency
During a partition, reject/block rather than serve stale data.
Banking, inventory, bookings, anything where wrong = costly.
Examples: traditional RDBMS, ZooKeeper, etcd, HBase.
vs
AP — choose availability
During a partition, keep answering; reconcile later.
Feeds, likes, shopping-cart adds, DNS, presence.
Examples: Cassandra, DynamoDB (tunable), Riak.
Consistency is a spectrum, not a switch
Model
Guarantee
Good for
Strong / linearizable
Every read sees the most recent write, globally.
Balances, locks, unique usernames.
Read-your-writes
You always see your own latest write (others may lag).
Profile edits, posting a comment.
Causal
Writes that depend on each other are seen in order.
Comment threads, reply chains.
Eventual
Replicas converge "eventually"; reads may be stale briefly.
Like counts, view counts, feeds.
Different features in the same system can use different models. A username uniqueness check is strong; the like counter on the same post can be eventual. Saying "I'd use strong consistency for X and eventual for Y" is exactly the granularity interviewers reward.
PACELC — the part people forget
CAP only talks about partitions. PACELC adds: Else (when the system is healthy), you still trade Latency vs Consistency. Waiting for a quorum of replicas to agree is slower than reading one local replica. So even on a good day, strong consistency costs latency. Tunable quorums (read R + write W > N for strong) let you slide along this dial per request.
Consistency isn't free even without failures — stronger guarantees cost round-trips and latency.
Quick check
A network partition splits your cluster. For a seat-booking system, the right behavior is:
CP — refuse. Selling the same seat twice is a correctness failure that's expensive to unwind. You sacrifice availability on the minority side to preserve a single source of truth. Compare to a "like" — there, AP is fine.
Quick check
A user updates their display name and immediately reloads their profile but sees the old name. Which guarantee was missing?
Read-your-writes. The write went to the primary; the reload hit a lagging replica. Route the user's own reads to the primary (or a caught-up replica) for a short window after a write to fix it — a common, expected refinement.
Practice before you move on
For an e-commerce checkout, assign a consistency model to each and justify in one line: (a) product page view count, (b) "items left in stock", (c) the final "place order" step, (d) recommendation list. Then state which are CP vs AP under a partition.