CAP and PACELC as decision aids rather than slogans

What it is

CAP says that a replicated system cannot, while a network partition separates its replicas, both answer every request on every side and keep every read consistent with every write. Brewer's 2012 retrospective (cited) states that the "2 of 3" formulation was misleading: CAP prohibits only a tiny part of the design space, perfect availability and consistency in the presence of partitions, and since partitions are rare there is little reason to forfeit either property when the network is healthy. Abadi's PACELC (cited) adds the case that matters every day: if there is a partition (P), the system trades availability against consistency (A or C); else (E), in normal operation, it trades latency against consistency (L or C). Kleppmann's critique (cited) surveys the ambiguities in CAP's definitions and warns that reading CAP as proof that eventually consistent databases are "more available" requires more careful reasoning.

Why it matters

Product pages label systems "AP" or "CP" as if it were a fixed property. The useful questions are per operation: what happens to a write on the minority side of a partition, whether a commit waits for remote replicas, and which reads must observe the latest write. The same store often answers differently depending on configuration (quorum sizes, synchronous or asynchronous replication, consistency level per request).

How to apply

• List operations that need an invariant across replicas (unique usernames, balances that must not go negative, "read your own write" after a form submission). These need coordination; everything else can tolerate staleness for some bounded time.
• For each store, find the documented behaviour under partition (what a minority does, whether writes are rejected or accepted and reconciled later) and under normal operation (what a commit waits for).
• Record the choice in PACELC terms in the decision record: "PA/EL for the activity feed, PC/EC for payments".
• Design partition mode explicitly: how it is detected, which operations are refused or queued, and how state is reconciled afterwards. Brewer's article frames this as planning for operation during a partition and recovery afterward.
• Make staleness visible: expose replica lag as a metric and set an upper bound that the product accepts.

Pitfalls

"CA" is not an option for anything that uses a network. "Consistency" in CAP means linearizability, not the C in ACID. "Availability" in CAP is about every non-failed node answering, not about uptime percentages. A single-node database with an asynchronous replica already faces the PACELC choice.