CAP & PACELC

The shop from Consistency models keeps its database in London and in New York. Each city serves its own customers from its own copy and forwards every change to the other. At 14:02 a transatlantic link fails and the two copies can no longer exchange messages: a network partition. Each replica now faces the same question with its next request. Answer from a copy that may be behind, or wait for a colleague it cannot reach?

The CAP theorem says a shared-data system can have at most two of consistency, availability and partition tolerance. Its proof is where the three words get their exact meanings. Read those before the slogan, because the slogan misleads.

The proof is the figure above. A write is confirmed in London while every message to New York is lost. A read then arrives in New York. If New York answers, it cannot know about the write, so the answer may be stale: not C. If it waits to hear from London, it never answers: not A. That is the whole theorem. It binds you only while messages are being lost; while the link is healthy, CAP says nothing.

So "pick two of three" is wrong in a specific way. You cannot pick away P: networks drop messages whether you like it or not, so the "2 of 3" formulation is misleading. The honest reading: when a partition happens, you must choose between C and A.

One subtlety: a replica cannot tell a lost message from a slow one, so in practice a partition is declared by a timeout. Choose the timeout and you have chosen how often you face the choice.

The choice is made per operation, by asking what a wrong answer would cost:

Databases follow the same logic: most let you choose per read or per write. That is why calling a whole database CP or AP hides more than it tells. Ask instead what each operation does when the link is down.

There is a third answer: give up a little of both. The recipe is to detect the partition, enter an explicit partition mode that allows some operations and limits others, and run a recovery step when the link returns. The cart above does this. The cash machine at the end of this article does it with money.

Partitions are rare. What is not rare is the write made in London that must also exist in New York. CAP is silent about this normal case. PACELC ("pass-elk") fills the gap: if there is a Partition, trade Availability against Consistency; Else, trade Latency against Consistency. The second half is the trade you pay on every replicated write, all day, on a healthy network.

The arithmetic is unforgiving. Suppose a write commits on the local copy in 2 ms:

• A synchronous replica write waits for New York to confirm before answering: one transatlantic round trip, about 70 ms (measured, August 2026). 2 + 70 = 72 ms, and the customer is told the change exists in both cities.
• An asynchronous write answers after 2 ms and sends the copy afterward. For those milliseconds New York is behind, and if London dies first the write dies with it.

Systems can be classified by both halves. Note how the letters split. PA/EL systems give up consistency in both situations, which keeps them simple. PC/EL systems accept stale reads every day for speed, yet stop writes rather than diverge during a partition.

Many cloud databases sell this dial as a single setting. Replicate to the other region in the background and answer at once, or wait for the other region before answering and pay its distance on every write. That is EL versus EC, one checkbox.

Two acronyms get thrown at this trade-off. ACID describes transactions. BASE is its deliberate opposite: where ACID is pessimistic and forces consistency at the end of every operation, BASE is optimistic and accepts that consistency will be in flux.

Two warnings. First, BASE is a slogan, not a definition: both acronyms are more mnemonic than precise, the two are ends of a spectrum, and BASE was first defined as simply anything not strictly ACID. Second, ACID's C and CAP's C differ. ACID's C is about invariants, such as unique usernames; CAP's C is about behaving like one copy, a much narrower property. And you cannot keep ACID's invariants across a partition either: recovery has to restore them.

The classic example is the cash machine. The invariant: a balance is never below zero. Cut off from the bank, a machine could refuse every withdrawal (C) or dispense anything (A). Real ones do neither: in stand-in mode they cap what you can take out at some limit, say $200, then reconcile when the link returns and charge a fee if the balance went negative. A bounded violation, repaired later, is the middle of the spectrum, and it is how banking has always worked.