Data Architecture
CAP Theorem
A bank runs one joint account from two data centers, one on each coast. Every withdrawal clears only after the two centers check with each other, so they can never disagree about the balance. Then the line between them goes down — and the next withdrawal at each coast forces a question the bank has never had to answer.
DC-East
$100
DC-West
$100
1/5 Both account holders ask for $80 at the same moment — one at each data center.
When the link between two data centers drops, the bank either declines withdrawals it can't verify or approves them blind — never both.
Go deeper ↓
A system whose parts can’t reach each other can stay correct or stay available, not both — and network splits are inevitable, so that trade-off is forced, not chosen. Everything here is optional; the sim above is the whole idea.
Two full copies, no referee
Each data center holds a complete copy of the account and can serve a withdrawal on its own. While the link is up, the two copies coordinate on every write: a withdrawal clears only once both centers have agreed to it, so the balance is always the same on both sides and can’t go negative.
A partition — the link between the centers failing, so neither can reach the other — breaks that agreement. You might expect the centers to “vote” on what to do — but a vote needs a majority, and neither side of a two-way split has one. With two copies and no referee, each center is left with two honest options: wait until it can confirm with the other (and refuse withdrawals until then), or act alone on the copy it has (and accept that the two copies will drift apart). That is the consistency-versus-availability choice, and the partition forces it.
Adding a third center in a third location is the usual fix: a 2-of-3 majority can still form when any one link fails. It changes the odds, not the rule — lose two links and the survivor is back to the same choice.
Where real systems land
| System | Under a partition | Leans |
|---|---|---|
| RDBMS with synchronous replication (e.g. Postgres with a sync standby) | Refuses writes it can’t confirm on the replica | Consistency |
| A single-leader RDBMS whose leader is cut off | Reads may continue; writes stall until a new leader is promoted | Consistency |
| Dynamo-style stores (Cassandra, Riak, classic single-region DynamoDB) | Accept reads and writes on any reachable replica, reconcile afterward | Availability |
| DNS resolution | Resolvers keep answering from cached records even when they can’t reach the authoritative server | Availability |
Most production systems are tunable rather than fixed at one end — per-query consistency levels, quorum sizes, timeouts — so “where it leans” is the honest description, not “which two letters it picked.”
About that triangle
CAP is almost always drawn as a triangle with Consistency, Availability, and Partition tolerance at the corners, and the system “picking two.” Shown once, to be taken apart, it is worth seeing — but it is a poor way to learn the idea, for two reasons:
- It’s contorted. The triangle implies one steady three-way trade-off. The real situation has two distinct phases: normal operation, when a well-built system delivers consistency and availability at once, and a partition, when it must make a single binary choice. A triangle can’t show “fine until a fault, then one decision.”
- It’s biased. Putting “CA” on the triangle implies that giving up partition tolerance is a real option and that P is something you choose. In any system that talks over a network, partitions happen whether you plan for them or not. The only genuine choice is what to do when one occurs.
This is why the sim never shows a triangle or a “pick two.” It shows a cable you can cut and two centers that then have to decide.
PACELC: the part CAP leaves out
PACELC extends CAP with the part CAP leaves out: if there is a partition, trade availability against consistency (the CAP choice); else, in normal operation, trade latency against consistency. Even with every link healthy, keeping copies in lockstep costs round-trips — so the same tension shows up as speed, not just as behaviour under failure.
“Eventually consistent” and last-write-wins
An availability-first system that let its copies diverge has to reconcile them once the link is back. The sim does the simplest honest thing — it replays both withdrawals against the true starting balance and flags the overdraft. Real systems often reconcile with last-write-wins: whichever update has the newer timestamp survives, the other is silently dropped. That resolves the conflict but can lose a write, and clock skew between machines makes “newer” less certain than it sounds. Conflict resolution (LWW, version vectors, CRDTs) is its own topic and isn’t modelled here.
Where the choice shows up elsewhere
Same fork, different setting — roughly ordered from consistency-leaning to availability-leaning:
- An ATM network cut off from the bank’s core. Many ATMs will still dispense cash up to a capped amount while offline, accepting the risk of a small overdraft rather than turning every customer away — a deliberate lean toward availability, bounded by the cap.
- A shopping cart during a data-center split. Carts almost always stay available: a customer can keep adding items on either side, and the copies are merged on heal (usually by keeping the union of items). A wrong cart is cheap; a checkout that refuses to load is not.
- An authoritative multiplayer game server, partitioned from a region. Games pick consistency for anything that must stay single-valued — currency, trades, ranked results — and will freeze or disconnect affected players rather than let two versions of the world diverge and then fight to reconcile.
- Coordination services (ZooKeeper, etcd, Consul). Strongly consistency-first by design: the minority side of a partition stops serving writes entirely, because their whole job is to be the referee other systems trust.
- Eric Brewer, “CAP Twelve Years Later: How the ‘Rules’ Have Changed” (2012).
- Martin Kleppmann, Designing Data-Intensive Applications, ch. 9 (“Consistency and Consensus”) — and his note that the CAP theorem as usually stated is too narrow to be useful.
- Daniel Abadi, “Consistency Tradeoffs in Modern Distributed Database System Design” (2012) — the PACELC formulation.