CAP, PACELC and consistency models — every question, written out
What the theorem actually says, the half of PACELC everyone forgets, and the difference between the consistency guarantees people name and the ones they mean.
What is wrong with "CAP means you pick two of consistency, availability and partition tolerance"?
Code diagnosis
Partition tolerance is not a choice — partitions happen to you, so the only real choice is what to do during one.
Any distributed system must tolerate partitions, because networks fail whether or not you have planned for it. The theorem is a statement about what happens WHEN one occurs: the minority side either refuses writes, or accepts them and diverges. There is no third option and no amount of engineering removes the choice.
See it run — Watch the minority side refuse writes for the whole partition.
You choose availability during a partition. What have you actually agreed to?
Trade-off & selection
That some keys will hold two different values, and that somebody has to decide which one survives.
Accepting writes on both sides of a partition produces two histories for the same key. Reconciliation is then an application decision, and the common default — last write wins by timestamp — is a decision to silently discard one user’s update. Choose AP only where you can say what reconciliation means for your data.
See it run — Count the updates discarded when the partition heals.
PACELC extends CAP. What does the "ELC" half say, and why does it matter more day to day?
Comparison
Else — when there is no partition — you still trade Latency against Consistency, on every single request.
Partitions are rare; requests are constant. The latency-consistency trade is paid on every read and write for the entire life of the system, and it is usually the more consequential of the two. Most systems are chosen on the partition behaviour and then live with the latency behaviour.
A four-node cluster requiring a majority is split exactly two-and-two. What happens?
Edge case reasoning
Neither side has a majority, so neither accepts writes. The data is safe and completely unavailable.
A majority of four is three, and an even split gives each side two. Both step down, which is correct and totally unavailable — and it is why quorum systems are built with odd node counts. Adding a fifth node makes an even split impossible.
See it run — Both sides refuse. Nothing diverges and nothing is writable.
Somebody says their system is "strongly consistent". What should you ask?
Comparison
Which guarantee they mean — linearizability, serializability, or something weaker that sounds like both.
Linearizability says every operation appears to take effect at a single instant between its start and its return — a guarantee about one object in real time. Serializability says a set of transactions is equivalent to some serial order, with no claim about real time. They are independent, and "strongly consistent" is used for both and for neither.
A user changes their profile picture, the page reloads, and the old picture is still there. What is happening?
Code diagnosis
The write went to the leader and the read went to a follower that has not applied it yet.
This is a stale read from replication lag, and it is the one form of staleness users reliably report as a bug — because it is their own change. The fix is a session guarantee: route the session to the leader for a short window after it writes, or carry the write position and let the replica wait until it has caught up.
See it run — Watch the share of reads that miss the reader’s own write.
A user refreshes twice and sees a newer value, then an older one. Which guarantee is missing?
Edge case reasoning
Monotonic reads: a session never sees time run backwards.
Two reads from a session landed on replicas with different amounts of lag. Monotonic reads is provided by pinning a session to one replica — cheap, and it removes the failure users find most alarming, because a value disappearing reads as data loss.
See it run — The reversal count drops to near zero.
Two concurrent writes to different replicas are reconciled by "last write wins" on a timestamp. What is the cost?
Trade-off & selection
One update is discarded, silently, and which one is decided by whichever machine’s clock was ahead.
A timestamp cannot distinguish a concurrent write from an ordered one, so last-write-wins resolves genuine conflicts by comparing clocks on different machines. It is the default in many systems, it looks like it works because conflicts are rare, and every conflict it resolves loses data.
See it run — Count the concurrent writes silently discarded.
What does a vector clock give you that a timestamp does not?
Comparison
It can tell a concurrent write from an ordered one, so the conflict is detectable.
A vector dominates another when every entry is at least as large and one is greater — that means it saw the other. Neither dominating means concurrent, which is a fact a timestamp cannot represent. The cost is that the vector grows with the writer count, and that concurrent is an answer the application now has to handle.
See it run — Every concurrent write is detected and none is discarded.
In a five-replica system, which read and write quorums guarantee a read sees the latest write?
Complexity derivation
Any R and W where R + W > 5 — for example W=3, R=3, or W=5, R=1.
If the read set and the write set must share at least one replica, then R + W has to exceed the replica count. That overlap is the entire mechanism, and it is the same intersection argument that makes two majorities impossible during a partition.
What invariant does causal consistency preserve that eventual consistency does not?
Invariant identification
If one operation could have influenced another, everyone observes them in that order.
Causal consistency prevents the failure where a reply appears before the message it replies to. Operations with no causal relationship may be observed in any order, which is what makes it far cheaper than total ordering while still eliminating the anomalies users notice.
Which of these genuinely requires linearizability?
Trade-off & selection
A distributed lock or leader election, where two holders at once is a correctness failure.
Linearizability is expensive and is needed where the invariant is about uniqueness or exclusion at a single instant. Locks, leader election and uniqueness constraints qualify. Most application data does not, and the useful skill is telling the difference rather than defaulting to the strongest guarantee.
How does a node tell "the network is partitioned" from "the other node has crashed"?
Edge case reasoning
It cannot. Both look identical from the outside, which is why the safe response to either is the same.
The impossibility of distinguishing a slow node from a dead one is the foundational result the whole field is built on. This is why quorum is the answer: it does not require knowing why the other nodes are unreachable, only how many you can still reach.
A quorum system suffers split brain in production despite requiring a majority. What is the most likely cause?
Code diagnosis
The configured cluster size was never updated when nodes were added.
Membership changes are the hard part of every consensus implementation, which is why Raft specifies joint consensus for them. Grow a cluster from three to five without both halves agreeing on the size and two nodes can each believe they hold a majority.
See it run — Two leaders, with the quorum rule switched on the whole time.
An interviewer asks you to justify choosing an AP store for a shopping cart and a CP store for the payment ledger. Explain it.
Explain it plainly
A cart is a set, and adding to a set commutes — two concurrent adds on different replicas can be unioned and the result is what both users intended. So during a partition I would keep accepting cart writes, because the reconciliation is well defined and the alternative is telling a customer they cannot add an item. A ledger is the opposite: entries are not mergeable, and accepting writes on both sides means two balances for one account, where reconciling means deciding whose money to delete. So the minority side refuses writes, some users get an error for the duration, and that is the correct outcome. The general rule is that AP is available when your data type has a merge function you can defend, and CP is required when it does not.
The distinction is what the data can tolerate and what reconciliation would mean. A cart is mergeable and a lost item is recoverable; a ledger is not mergeable and a lost entry is money.
A store offers per-query consistency levels. When is it right to use the weaker one?
Trade-off & selection
When the read feeds a decision that a later check will catch anyway, or when being seconds out of date is invisible.
Consistency is a per-operation property, not a system-wide one. A profile read can be seconds stale; the uniqueness check on a username cannot be stale at all. The discipline is deciding deliberately per query rather than picking one level and applying it everywhere.