CAP Theorem

First PublishedMar 1, 2026ByAtif Alam

The CAP theorem is a useful lens for system design: when a network partition occurs, you cannot have all three of Consistency, Availability, and Partition tolerance.

In practice, partitions happen—so the real choice is CP (consistent but may be unavailable during a partition) or AP (available but may return stale or inconsistent data during a partition).

This page explains the three properties and how that choice shapes your design.

What CAP Is

Consistency — Every read sees the latest write. All nodes agree on the same view of the data at any moment (linearizability / strong consistency).
Availability — Every request receives a response (no indefinite blocking or refusal). The system keeps serving reads and writes.
Partition tolerance — The system continues to operate despite network partitions (messages between nodes are delayed or lost).

In the presence of a partition, you can have at most two of the three. Because partitions occur in real networks, P is usually fixed—so you are effectively choosing between CP and AP.

CP vs AP

CP (Consistency + Partition tolerance) — When a partition happens, the system prefers consistency. It may refuse or delay responses (e.g. wait for quorum, or return errors) so that any response it does give is correct.

Typical for: financial balances, inventory, anything where stale or conflicting data is unacceptable. Single-leader databases with sync replication, or quorum-based systems, often behave as CP.

AP (Availability + Partition tolerance) — When a partition happens, the system stays available. It responds to every request but may return stale or inconsistent data (e.g. from a replica that hasn’t received the latest write).

Typical for: social feeds, caches, presence, recommendations—where eventual consistency is acceptable and availability matters more than immediate correctness.

Use CP when correctness is non-negotiable; use AP when you can tolerate temporary inconsistency and handle it in the application (e.g. conflict resolution, last-write-wins, or user-visible staleness).

When a Partition Happens

A partition is when the link between two data centers (or two availability zones) fails—two groups of servers can’t talk to each other.

The examples below show how systems behave during a partition: CP systems refuse or delay to stay correct; AP systems keep serving and may return stale or conflicting data.

  [Region A]  ==========X==========  [Region B]
   (servers here can't talk to servers there)

Example 1 — Two-region database (primary + replica)

Setup: Primary in Region A, replica in Region B; apps in both regions.

  Region A                    Region B
  +-------------+            +-------------+
  | Primary DB  | ----X----   | Replica DB  |
  +-------------+ (partition) +-------------+
  App                           App

Partition: Link between A and B fails; the two sides can’t replicate.

CP: Writes that require sync replication (or quorum) block or fail; the primary (or app) refuses or delays until the replica is reachable, so any answer we give is correct. Reads that must see the latest may also be refused.

Outcome: consistent view, but some requests get “unavailable” (errors or timeouts).

AP: Each region keeps accepting requests—we’d rather answer with what we have than refuse. Writes might go to the local primary only; reads might be served from a stale replica. When the partition heals, you reconcile (e.g. conflict resolution, last-write-wins).

Outcome: available, but possibly inconsistent until reconciliation.

Example 2 — Bank balance / inventory (CP)

Setup: Balance (or inventory count) replicated across two data centers; a debit or decrement must not double-apply.

  DC A                         DC B
  +-------------+             +-------------+
  | Balance     | ----X----   | Balance     |
  +-------------+ (partition) +-------------+
  Debit request                 Can't coordinate
  → Refuse (CP): "try again later"

Partition: The two DCs can’t communicate.

CP behavior: One side refuses to perform a debit (or inventory decrement) until it can coordinate with the other, to avoid double-spend or overselling. The user might see “try again later” or a timeout. We choose consistency so we never hand out wrong balance or sell the same item twice.

Setup: User posts in Region A; the feed is also served from Region B (replicated or cached).

  Region A                    Region B
  +-------------+             +-------------+
  | User posts  | ----X----   | Serves feed |
  +-------------+ (partition) +-------------+
  New post written            Stale copy (AP)
  → Post appears in B when link is back

Partition: A and B are cut off.

AP behavior: Region B keeps serving the feed from its (possibly stale) copy; the new post is not visible there until the partition heals and data syncs. You might show “posts may be delayed.” We choose availability so users always see a feed, even if it’s briefly outdated.

In each case, the partition forces a trade-off: the system either preserves correctness and risks unavailability (CP) or stays available and tolerates temporary inconsistency (AP).

Why It Matters for System Design

When you want both high availability and strong consistency, you are in CAP territory.

You either: (1) favor one over the other (CP or AP), (2) relax consistency (eventual consistency, read-your-writes, or tunable consistency), or (3) narrow the window of inconsistency with design choices—e.g. single-leader with failover, or tunable read/write concern so critical paths get stronger guarantees.

The Requirements page calls this out under Availability: “High availability + consistency together → you’re in CAP theorem territory.”

For deeper material—PACELC (the “else” when there is no partition: latency vs consistency), strong vs eventual consistency, read-your-writes, and tunable consistency—see Consistency Models in Data Reliability.