The CAP Theorem: Why P is Not Optional

The Three Guarantees

• C — Consistency: Every read returns the most recent write, or an error. No stale data is ever served.
• A — Availability: Every request receives a non-error response. The system is always up, but the response may not reflect the most recent write.
• P — Partition Tolerance: The system continues to operate even when network communication between nodes fails.

Why P is Not a Choice

In any real distributed system, network partitions are not a theoretical risk — they are a certainty. Networks drop packets. Data centers lose connectivity. This means partition tolerance is a requirement, not a choice. Every practical distributed system must choose P.

Since P is mandatory, the CAP theorem reduces to a single real choice: when a network partition occurs, does your system prioritize Consistency or Availability?

• Choose Consistency (CP): A node that can't confirm it has the latest data returns an error. The system is unavailable until the partition heals.
• Choose Availability (AP): A node returns its current value, which may be stale. The system stays up but may serve incorrect data.

Category	Behavior	Examples
CP	Sacrifices availability to prevent inconsistency. Returns errors during partitions.	ZooKeeper, MongoDB (configurable), HBase
AP	Sacrifices consistency to remain available. Returns best available (possibly stale) data.	Cassandra, DynamoDB, CouchDB
CA	Consistent and available — only possible with no partitions, i.e., a single machine.	Single-node PostgreSQL (theoretical)