PACELC extends CAP with an "else" branch. Why does that branch matter more in day-to-day operation?
Show the full answer Hide the answer
What is being tested
Whether you recognise which half of the trade-off you actually live with.
The reasoning
CAP describes behaviour during a partition: consistency or availability, pick one. Partitions happen, and for most systems they happen rarely.
PACELC adds: else, latency or consistency. That is the normal case — every request, every day.
A system that chooses consistency in the "else" branch pays a coordination round trip on every write. Cross-region, that is 60–150 ms added to each one, forever. Over a year that cumulative cost usually dwarfs the partition behaviour everyone argues about in design reviews.
So the more useful question is not "what happens during a partition" but "what does this cost me when everything is working?"
The decision that actually resolves it
Asymmetry of failure cost, per operation.
A false decline is recoverable — the customer retries, the terminal falls back. A double-spend is unrecoverable and scales with the duration of the problem.
| Operation | Choice | Why |
|---|---|---|
| Authorisation against a shared balance | CP | Double-spend cannot be undone |
| Low-value contactless under a floor limit | AP | Bounded, insurable loss |
| Recording a completed settlement | AP | Append-only; no shared invariant |
| Fraud scoring | AP, degraded | A stale model beats no decision |
Card networks are explicitly hybrid: offline stand-in processing exists because the network chose AP with a value cap for a defined class of transaction. The cap is the risk control that makes availability affordable.
The practical trap
Two regions cannot form a quorum. A two-region active-active deployment with no witness in a third location has designed a system that cannot make a consistent decision during a partition — regardless of which letter it claims.