Why you always pick P

Here is the thing that confuses people: you don't actually get to choose between all three pairs (CA, CP, AP). In any distributed system, network partitions will happen. Cables get cut. Switches fail. Data centers lose connectivity. If your system runs on more than one machine, partition tolerance is not optional, it is a requirement.

So the real question is: when a network partition occurs, do you sacrifice consistency or availability?

Network partition happens between Node A and Node B:

CP choice:
  Client -> Node A: "Write x = 5"  -> OK
  Client -> Node B: "Read x"       -> ERROR (can't confirm latest value)

AP choice:
  Client -> Node A: "Write x = 5"  -> OK
  Client -> Node B: "Read x"       -> Returns x = 3 (stale but available)

A CP system will refuse to serve a read if it cannot guarantee the data is current. An AP system will always give you an answer, even if it might be outdated.

CP vs AP: real systems

Let's look at where real databases and systems fall on this spectrum.

The "CA" myth

You sometimes see people say "a single-node PostgreSQL database is CA." That is technically true but useless, a single machine has no network partitions because there is no network between nodes. The moment you add a second node, you are in CAP territory and you must choose.

Some people list traditional RDBMS systems as CA. What they mean is: "when running on a single node, it is both consistent and available." But that is not a distributed system, so CAP does not apply. Don't let this confuse you.

PACELC: the extended model

The CAP theorem only describes what happens during a partition. But most of the time, your system is running fine with no partition. Daniel Abadi proposed the PACELC model to cover both cases:

• Partition? Choose Availability or Consistency
• Else (no partition)? Choose Latency or Consistency

This is the more useful mental model because the "normal operation" tradeoff matters far more than the partition-time behavior (partitions are rare).

Cassandra: the tunable example

Cassandra deserves a closer look because it lets you choose your consistency level on every single query. This is incredibly powerful.

// AP behavior - fast, but may return stale data
SELECT * FROM users WHERE id = 123
  WITH CONSISTENCY ONE;

// CP behavior - slower, but guaranteed fresh
SELECT * FROM users WHERE id = 123
  WITH CONSISTENCY QUORUM;

// Strongest guarantee - all replicas must respond
SELECT * FROM users WHERE id = 123
  WITH CONSISTENCY ALL;

With a replication factor of 3, QUORUM means 2 out of 3 replicas must agree. This gives you strong consistency for critical reads (account balance) while allowing eventual consistencyWhat is eventual consistency?A guarantee that all copies of data will converge to the same value given enough time, rather than being instantly synchronized after every write. Ask AI for more for non-critical reads (user profile view count).

The formula is simple: if R + W > N (read replicas + write replicas > total replicas), you get strong consistency. With N=3, QUORUM for both reads and writes means 2 + 2 > 3, strongly consistent.

Practical takeaway

Don't think of CAP as a rigid classification. Think of it as a spectrum that you navigate per feature:

• Your user's account balance? CP. Never show stale data.
• Your social feed's like count? AP. Being one second behind is fine.
• Your shopping cart? Depends. Some companies go AP (Amazon famously chooses availability for carts) because a customer adding an item to a cart that briefly shows the old count is better than showing an error page.

The best systems don't pick one side globally, they make different tradeoffs for different data and different operations. That is the real lesson of CAP.