CAP comes up routinely in distributed-systems interviews, and three misstatements can derail the design discussion. Candidates may say "available" when they mean "fresh," treat CAP consistency and ACID consistency as the same property, or label whole databases CP or AP as if the theorem stamped a permanent identity on a product. Each mistake leads to reasoning about the wrong requirement. The fix is to use the formal definitions and state the trade-off as a decision about how a defined object, API, or subsystem behaves during a network partition.

The formal grounding is short. Eric Brewer presented CAP as a conjecture at PODC in 2000, and Seth Gilbert and Nancy Lynch proved a formalized version in 2002. In their formulation, consistency means linearizability: completed operations appear in a single order that respects real-time precedence, as if there were one copy of the data. Availability means every request received by a non-failing node eventually gets a non-error response. Partition tolerance means the guarantees account for a network that can lose arbitrarily many messages between nodes. These definitions are narrower than their plain-English readings.

Misunderstanding one: availability means the data is there

In CAP, availability says nothing about whether a response contains current data. It requires that a non-failing node answer. A replica cut off from its peers for ten minutes can remain available in the CAP sense while serving a bank balance from before the partition.

This matters because "we need high availability" often means users should get useful, reasonably current responses within an acceptable time. That bundles uptime, latency, and freshness; CAP availability covers only the response requirement. During a partition, a design that continues answering from disconnected replicas may return stale data or accept writes that conflict with writes elsewhere. Whether that behavior is acceptable depends on the operation and the consequences of stale or conflicting data.

Misunderstanding two: CAP consistency is ACID consistency

The two uses of "consistency" are non-equivalent, though they can interact in one design. CAP consistency concerns the observable history of operations on replicated data; in the Gilbert and Lynch formulation, it is linearizability. ACID consistency concerns preserving application-defined invariants across a transaction. If debits and credits must balance, a transaction must move the database from one valid state to another. That requirement can apply on a single node or across a cluster.

Linearizability does not guarantee that two simultaneous observers return identical values. It requires operations to fit a legal sequential history that respects completed-before-started ordering. Nor does a linearizable balance read prevent two withdrawals from violating an account invariant. Enforcing that check may require an atomic or suitably isolated transaction. Conversely, a database can preserve transaction constraints on one node without addressing disagreement among replicas. Naming the required observation and transaction properties makes the design discussion concrete.

Misunderstanding three: CAP is a permanent "pick two" rule

The popular framing presents C, A, and P as a menu from which you choose two. For a multi-node system on a real network, assuming away communication failures is generally unrealistic. Links and switches fail, and pauses or overload can make a healthy node indistinguishable from an unreachable one. A design still has to specify what happens when replicas cannot communicate.

The theorem constrains behavior during a partition rather than assigning a permanent identity to the system. When the network is healthy, the relevant trade-offs include latency, durability, and consistency. Daniel Abadi's PACELC formulation captures the broader distinction: if there is a partition, trade availability against consistency; else, consider latency against consistency. The latency implication depends on the service boundary and guarantees. A replicated service that acknowledges a write only after a quorum has made it durable, and that supports failover without losing acknowledged data, pays for cross-replica coordination. A single-leader path with weaker durability or different read routing may pay a different cost. Brewer's 2012 retrospective, "CAP Twelve Years Later", likewise argues that the "two of three" phrasing obscures the work of detecting partitions, operating through them, and recovering afterward.

The relevant partition boundary is the communication path among replicas participating in the guarantee for a logical object or API. Hosts, processes, and containers matter when they define those participants or their failure scopes, but deployment topology alone does not establish the CAP boundary.

CP and AP describe scoped guarantees, not products

Linearizability applies to a history of operations on an object or defined API boundary. CAP availability applies to whether requests reaching non-failing participants receive non-error responses. An isolated read or write is therefore not independently "CP" or "AP," and one database can expose APIs with different scoped guarantees.

Consider three replicas, A, B, and C, for one key-value object. A begins as leader. Writes route to the current leader and commit only after acknowledgment from a majority. Elections also require a majority, and terms or fencing tokens prevent an old leader from committing after a new leader is elected. A partition isolates A from B and C. A cannot reach a quorum, so it rejects or cannot complete writes. B and C can elect a new leader and continue committing writes; clients that reach or reroute to that majority side can progress.

If A continues serving local reads, a read after a B-side write has completed may return the older value. The resulting read-write history is not linearizable. If every non-failing replica still answers those reads, that read API may satisfy CAP availability while giving up linearizability. The write API is not CAP-available to requests reaching isolated A because those requests fail. If the service instead requires reads to contact the leader or a quorum, it can preserve linearizability for successful operations but must reject minority-side reads as well. The service as a whole is therefore poorly described by one CP or AP label.

Martin Kleppmann makes this case in "Please stop calling databases CP or AP": many systems are neither linearizable nor CAP-available under the formal definitions, so forcing them into two buckets misstates their guarantees. If you use CP and AP as shorthand, define the object or API, the operation history, and the partition-time behavior they describe.

Calibrating the choice: balances, carts, and likes

The right behavior depends on the operation, its invariants, and the consequences of rejection, staleness, or conflict.

For a withdrawal authorized against one globally shared balance, accepting independent writes on both sides of a partition can violate a no-overdraft rule. A quorum-based design may continue on the majority side while rejecting the minority side, but linearizable reads alone are insufficient; the balance check and decrement also need atomic or suitably serializable enforcement. Other designs can preserve the invariant without rejecting every request everywhere. Escrow can allocate spending rights to partitions, and bounded offline authorization can permit limited withdrawals within a predefined risk budget.

A cart can favor availability when the operation is an add, inventory and price are validated at checkout, and the merge policy is explicit. Those assumptions matter. Naive reconciliation can make removals reappear or mishandle concurrent quantity changes. Scarce inventory, reservations, promotions, or price guarantees may require coordination for the affected operations even if ordinary cart edits remain available.

A displayed likes counter can accept temporary divergence when it is informational and reconciliation is well defined, potentially through a mergeable counter or CRDT-style design. The choice changes if likes affect ranking, monetization, moderation, access, or fraud detection. Those paths may need deduplication, stronger ordering, bounded staleness, or separate authoritative records even while the displayed count remains eventually consistent.

These cases can use similar replication machinery while making different choices because both domain consequences and available mechanisms shape the design.

What to say instead of "it's AP"

State the decision at the boundary where the guarantee applies. Name the object or API, identify which replicas can form a quorum during the partition, and specify what each operation does on each side. Then describe the permitted staleness or conflicts, the invariant that must survive, and the recovery rule. Depending on those facts, the design may reject only minority-side writes, serve bounded-stale reads, degrade selected operations, reserve limited authority through escrow, or accept concurrent updates with a defined merge or CRDT.

For a balance, that explanation might require quorum-backed withdrawal authorization while allowing a cached balance estimate to remain readable. For a cart, adds may remain available while inventory reservation waits for an authoritative service. A single product will often need several such answers.

A useful CAP analysis identifies the guarantee boundary, partition-time behavior, and recovery semantics for each consequential operation. Those details connect the theorem's formal constraint to the service behavior that users and operators will actually encounter.