CAP & PACELC

The theorem, stated carefully. In the presence of a network Partition, you must choose between Consistency (every read sees the latest write, i.e. linearizability) and Availability (every non-failing node answers). You do not "choose two of three" — partitions are not something you opt out of, so the choice is only between C and A, and only during a partition.

Why "CP or AP" is misleading. The labels are much cruder than real systems. Most databases offer several consistency levels, configurable per operation; the same cluster can serve a linearizable read and an eventually-consistent one. And "consistency" in CAP means linearizability specifically — not the C in ACID, which is a different word for a different idea. Being precise about this is itself a senior signal, because sloppy CAP talk is extremely common.

PACELC is the more useful version. If there is a Partition, choose Availability or Consistency; Else, choose Latency or Consistency. The second half is the one that governs normal operation: making a write visible everywhere before acknowledging it costs a cross-node — often cross-region — round trip on every request. Partitions are rare; that latency bill is paid all day, every day. Most systems you'll design are effectively PA/EL or PC/EL.

In practice you decide per operation, not per system. Postgres with synchronous replication is consistent and pays latency; the same Postgres with async replicas serves fast, slightly stale reads. A shopping cart can be eventually consistent; a payment authorisation cannot. The strong answer in a design round is not "this system is AP" — it's "these three reads tolerate staleness and go to replicas, this one write needs linearizability and goes to the primary."

What availability means in an outage. If you pick consistency, define the degraded mode explicitly: read-only, reduced functionality, or an error. "Unavailable" as an unexamined outcome is not a design.

CAP is the most name-dropped and least precisely-used concept in system design interviews, so using it precisely stands out immediately. More practically, the question behind it — what does a user see when a node can't be reached — has to be answered for every design that replicates data, and PACELC is the framing that turns it into a per-operation decision rather than a slogan.

• Partitions aren't optional, so CAP is a choice between consistency and availability during one.
• "Consistency" in CAP means linearizability — not the C in ACID.
• Labelling a whole database CP or AP is too coarse; real systems tune consistency per operation.
• PACELC adds the everyday trade: without a partition you're still choosing latency versus consistency.
• The latency cost of strong consistency is paid continuously; the partition cost is paid rarely.
• Decide per operation — stale-tolerant reads to replicas, linearizable operations to the primary.
• If you choose consistency, state the degraded mode explicitly: read-only, reduced, or error.