CAP Theorem and PACELC in Plain English

The CAP theorem is one of the most quoted and most misunderstood ideas in distributed systems. Used properly, it’s a simple tool for reasoning about what happens when things go wrong.

The three properties

• Consistency (C): every read sees the most recent write, as if there were one copy of the data.
• Availability (A): every request to a working node gets a response.
• Partition tolerance (P): the system keeps operating even when the network between nodes fails.

What CAP actually says

Network partitions are not optional in distributed systems: networks fail. So the real statement is: when a partition happens, you must choose between consistency and availability.

• CP: refuse or delay some requests so no one sees stale or conflicting data.
• AP: keep answering on both sides of the partition, accepting that data may temporarily diverge and must be reconciled.

“CA” systems only exist when there is no network to partition, like a single-node database.

PACELC: the everyday trade-off

Partitions are rare. Daniel Abadi’s PACELC extends CAP to normal operation:

If there is a Partition, choose A or C; Else, choose Latency or Consistency.

Keeping replicas perfectly consistent means waiting for them to agree, which adds latency. Serving from the nearest replica is faster but may return slightly stale data.

In practice

Many databases let you tune consistency per request, for example by choosing how many replicas must acknowledge a read or write. Our guide to database replication explains these quorums. That means the same system can behave more like CP for payments and more like AP for a “likes” counter.

Common myths

• “Pick two of three.” You don’t get to drop partition tolerance in a distributed system.
• “NoSQL means AP.” Many NoSQL databases offer strong consistency options; see SQL vs NoSQL.
• “Eventual consistency means data is wrong.” It means replicas converge after a delay; designs must handle the delay safely.

Using CAP in interviews

When you add replicas or shards, say which operations need strong consistency and which can tolerate staleness, and why. That shows the reasoning interviewers look for in our system design framework.

Frequently asked questions

Is MySQL or PostgreSQL CP or AP?

A single-node relational database isn’t distributed, so CAP doesn’t really apply. With replication, behaviour depends on how you configure failover and replica reads.

What is eventual consistency?

A guarantee that, if no new writes occur, all replicas will eventually return the same value.

Is CAP still relevant?

Yes, as a way of thinking about failure. PACELC is often more useful for everyday design.