TL;DR - When the network splits a replicated system, each request gets either a real answer that may be stale or a refusal until the split heals. The design decision is which treatment each kind of data gets; on a healthy network the same dial trades latency against freshness.
30-second version (elevator pitch): "During a network partition a replicated system picks, per request, between answering with possibly stale data and refusing until the link heals. Partitions are a fact of the network, so I decide per data type: a shopping cart stays writable on both sides and merges later, while a bank balance or a unique username takes writes on the majority side alone. On a healthy network the same choice shows up as latency versus freshness, which is PACELC."
Two Data Centers and a Cut Cable
You run a service in two data centers, East and West, each with a full copy of the data and a replication link with a round trip of about 60 to 70 ms.
At 02:14 a fiber cut splits the sites for 90 seconds. Both sites are healthy and each sees its own replica alone. A user in East adds a sweater to her cart. A user in West withdraws 80 from an account whose balance reads 100 on both sides. Users in West and East both register the username "alice". Each request needs an answer now, with zero knowledge of the other side. That window is the whole subject of CAP.
What CAP Actually Says
What is a partition? A period during which some nodes are unable to exchange messages while every node keeps running. A slow link and a dead link look identical until a timeout fires.
What does consistency mean here? Linearizability: every operation appears to take effect at one instant between its start and completion, so once a write completes, every later read anywhere returns that value or a newer one. ACID consistency is a different idea: transactions keep invariants intact, such as a balance staying at or above zero.
What does availability mean here? Every request that reaches a live node eventually receives a real answer, as opposed to an error or a timeout.
The precise statement. During a partition, a system that answers on both sides will sometimes return stale data, because the sides have diverged. A system that keeps every answer linearizable has to refuse or delay requests on at least one side. You choose CP behaviour (refuse on one side) or AP behaviour (answer on both sides, accept divergence).
The common misreading. "Pick two of three" sounds like a permanent menu where CA is a valid order. Any system with two or more nodes will see partitions, so the real choice is behaviour during the partition, made per operation. One database can be CP for one table and AP for another.
PACELC: The Trade-off on a Healthy Network
PACELC covers the time when the link is up: if there is a Partition, trade Availability against Consistency; Else, trade Latency against Consistency. A write that waits for the far replica costs one 60 to 70 ms round trip; a local commit returns in a couple of milliseconds and far reads lag briefly.
- -PC/EC - Synchronous leader-based and consensus-backed stores: configuration, locks, ledgers.
- -PA/EL - Dynamo-style stores at default settings: carts, sessions, activity feeds.
Worked Scenario: Cart, Balance, Username
Shopping cart (AP, merge on heal). East accepts the sweater; West accepts socks added from the same user's phone. On heal, the copies merge by union and both items appear. A removal that raced an add resurrects the item, and the user deletes it again. Zero errors, fine for a cart.
Bank balance (CP, refuse on the minority side). If both sides accept the 80 withdrawal, the balance lands at -60 after the merge, and money has zero sensible merge rule. Place the account's leader in East. During the split, West returns "try again in a moment" for withdrawals. The user sees a short delay, and the invariant holds.
Unique username (CP, same shape). If both sides grant "alice", the heal produces two accounts with one name. A claim succeeds when a majority of replicas record it, so the majority side grants names and the other side asks the user to retry.
The pattern: data with an obvious merge rule goes AP; data with a global invariant goes CP.
Quorum Arithmetic
What is a quorum? With N replicas, a write completes after W acknowledgements, and a read waits for R replicas and returns the newest version. When W + R > N, every read set overlaps every write set in at least W + R - N replicas.
N = 3, W = 2, R = 2. Version 7 reaches A and B; C still holds version 6. Any read pair, {A, B}, {A, C} or {B, C}, contains A or B, so it returns version 7. Overlap is 2 + 2 - 3 = 1.
W = 1. Version 7 lands on A alone. A read of {B, C} returns version 6 with full confidence. Overlap is 1 + 2 - 3 = 0. Regaining overlap needs R = 3, so one slow node delays every read. During a partition, a majority quorum gives CP automatically: the side with one replica is short of W = 2 and refuses writes.
Where consensus sits. Raft and Paxos are the CP machinery: a majority elects a leader and acknowledges each log entry, so a minority is unable to elect a leader and refuses writes by construction. The username table and the ledger belong here; the cart has zero need for it.
Tunable consistency. Dynamo-style stores let each request choose W and R: one replica, a majority, or all. A cart write uses one; a username claim uses a majority.
Alternatives Worth Naming
- -Harvest and yield - Yield is the fraction of requests answered; harvest is the fraction of data each answer reflects. A search over 10 shards with one unreachable answers every query at 90 percent harvest.
- -Bounded staleness - Reads at most K versions or T seconds behind the leader.
- -Read-your-writes sessions - A session token carries the client's last write version, and reads route to a replica at least that fresh.
When to Use in Interviews
Bring up CAP whenever the design has two or more replicas and a user-facing write path. Name the data ("the cart"), name the split ("East and West apart for a minute"), and name what the user sees ("both sides keep accepting adds; we merge on heal"). Interviewers reward the per-data-type answer over a blanket "we pick AP".
Summary
- -The statement - During a partition, each request gets stale data or a refusal.
- -Consistency - Linearizability, distinct from ACID invariants.
- -"Pick two" is a misreading - Choose per data type.
- -PACELC - When healthy, trade latency against freshness.
- -Quorums - W + R > N gives overlap.
- -Merge rules decide - Obvious merge means AP; global invariant means CP.
Interview Q&A
- -Can I design a CA system? - On one node, yes. Add a replica and you choose CP or AP behaviour during splits.
- -Is a CP system down during a partition? - The minority side refuses writes; the majority side runs normally.
- -Why N = 3, W = 2, R = 2? - It survives one dead replica, and 2 + 2 > 3 gives overlap.
- -Where does eventual consistency fit? - It is the AP promise: replicas converge after the link heals.
- -How do you pick per data type? - Ask whether concurrent writes merge obviously. Carts do; balances and unique keys need CP.
Disclosure: I build Pretense, a local proxy that swaps detected secrets, PII and, inside fenced code blocks, code identifiers for stand-in tokens before a prompt leaves the laptop; identifiers come back byte-exact and secrets stay as stand-ins. The replica configs and connection strings you paste when asking an AI assistant about quorum settings should travel as stand-ins.
From the System Design Laws newsletter.
