AnyLearn
All lessons
Computer Scienceintermediate

The CAP Theorem

Why every distributed system has to give up something when the network splits. CAP, the trade-offs in real databases, and the PACELC extension that's usually more useful in practice.

Updated · AI-authored, review-gated · how lessons are made

capdistributed-systemsconsistencyavailability
Part of:System Design Fundamentals
Not signed in: your progress and quiz score won't be saved.
Progress1 / 8

What CAP actually says

The CAP theorem, formalised by Eric Brewer in 2000, says a distributed system can guarantee at most two of three properties at any moment:

  • C — Consistency: every read sees the most recent write (linearisability).
  • A — Availability: every request gets a non-error response.
  • P — Partition tolerance: the system keeps working when nodes can't talk to each other.

The usual visualisation (a triangle, pick two) is misleading. In reality networks will partition — packets get dropped, switches fail, racks lose power. P isn't really optional. So the practical choice is between C and A during a partition. CAP is really "CP vs AP under partition".

Full lesson text

All 8 steps on one page, for reading, reference, and search.

Show

1. What CAP actually says

The CAP theorem, formalised by Eric Brewer in 2000, says a distributed system can guarantee at most two of three properties at any moment:

  • C — Consistency: every read sees the most recent write (linearisability).
  • A — Availability: every request gets a non-error response.
  • P — Partition tolerance: the system keeps working when nodes can't talk to each other.

The usual visualisation (a triangle, pick two) is misleading. In reality networks will partition — packets get dropped, switches fail, racks lose power. P isn't really optional. So the practical choice is between C and A during a partition. CAP is really "CP vs AP under partition".

2. Why network partitions are inevitable

It's tempting to wave away CAP as theoretical. Don't. Real-world partition events:

  • A rack switch fails; half the cluster is unreachable for 90 seconds.
  • A cloud region has an internal networking incident lasting 8 minutes.
  • Cross-region replication runs over the public internet; transient drops happen daily.
  • A garbage collection pause makes a node look partitioned to its peers for 30 seconds.

These aren't black-swan events; they're tuesday. Any distributed system that hasn't been tested under partitions hasn't been tested. The question is just how the system behaves when one happens — and that's what CP vs AP encodes.

3. CP systems: refuse to serve stale reads

A CP (consistency + partition-tolerant) system, when partitioned, will refuse some requests rather than risk returning out-of-date data.

Examples and how they behave:

  • etcd / Consul / ZooKeeper: writes need a quorum; without one, writes hang or error. Reads can be linearisable (require quorum) or stale (faster, but you're back to AP-ish).
  • MongoDB (with strict concerns) and HBase lean CP.
  • CockroachDB, Spanner: globally consistent — they sacrifice availability for the minority side of a partition.

The trade-off: an etcd cluster with 3 nodes and 2 down stops accepting writes. That's correct CP behaviour. Whether it's right for your system depends on whether you'd rather show users an error or show them stale data.

4. AP systems: serve something, always

An AP (availability + partition-tolerant) system always responds, even if the response is based on stale data.

Examples:

  • Cassandra, DynamoDB: tunable consistency, but defaults lean AP. Writes succeed on whatever nodes are reachable; conflicting writes are merged later (last-write-wins or CRDTs).
  • CouchDB, Riak: classic AP designs.
  • DNS: read availability is the entire point; "this name resolves to whatever record is in your nearest cache" is by design.

The trade-off: two clients on opposite sides of a partition can write conflicting values; the system reconciles afterward. Apps need to be okay with eventual consistency — bank balances are not, shopping cart contents probably are.

5. PACELC: the more useful version

PACELC extends CAP to talk about the normal case too:

If a Partition happens, the system trades Availability or Consistency. Else (no partition), it trades Latency or Consistency.

Most systems are either PA / EL (Cassandra, Dynamo: prefer A under partition, prefer L normally) or PC / EC (etcd, Spanner: always pick C).

This is more honest because even with no partition, consistency has a latency cost — strong reads need quorum, which means cross-node round-trips. PACELC says "you're paying for consistency every day, not just on the bad days".

6. How CP and AP behave during a partition

Same network event, different choices.

flowchart LR
  Partition["Network partition"] --> CP["CP system: refuse writes on minority side"]
  Partition --> AP["AP system: accept writes on both sides"]
  CP --> Safe["No conflicts, possibly slow / unavailable"]
  AP --> Reconcile["Conflicts to merge later"]

7. Mapping CAP to product decisions

The right answer depends on the data:

DataPrefer
Account balance, financial transactionsCP — never lie about money
Shopping cart, draft post, user prefsAP — "slightly stale" is fine, never "unavailable"
Inventory count for a flash saleCP — overselling is worse than slowness
Like counts, view countersAP — slightly stale numbers are universal
Critical config (feature flags)depends — flags off-by-error are usually safer
User-facing reads in social feedsAP — staleness is invisible at human time scales

Most real apps end up using both: a CP store for the core transactional data, an AP store (or cache) for the read-heavy display layer. CAP is a property of a particular store, not of your whole product.

8. Common misconceptions

Things people say about CAP that are wrong:

  • "You pick C, A, or P at design time." No: P is forced by reality. You pick between C and A when a partition happens.
  • "CP systems are unavailable." Only the minority side during a partition. The majority quorum keeps serving.
  • "Eventual consistency = no consistency." AP systems do converge — eventually. "Eventually" in practice is usually milliseconds; pathologically it can be hours during long partitions.
  • "CAP is dated; we have new theorems now." PACELC extends it; FLP is a different question entirely (consensus under async). CAP is still the right starting frame for replicated stores.
  • "My single-region DB doesn't need to think about CAP." Replication across AZs is enough to make CAP relevant. Even a primary-replica setup faces partitions.

Check your understanding

The lesson ends with a 5-question quiz. Take it in the player above to see your score.

  1. Why is the framing "pick any 2 of CAP" misleading in practice?
    • Modern systems can have all three
    • Partition tolerance isn't really optional — networks fail — so the real choice is C vs A *during a partition*
    • CAP only applies to NoSQL
    • P stands for something different now
  2. Your team uses Cassandra with default consistency for the user feed. Under a brief partition, what's the expected behaviour?
    • All writes will block until the partition heals
    • Both sides will accept writes; reconciliation happens later, possibly with conflicting values
    • The cluster becomes read-only
    • Cassandra refuses new connections
  3. Which workload is the strongest fit for a CP system?
    • A like counter on social posts
    • An inventory counter during a flash sale where overselling is unacceptable
    • A non-critical view-count counter
    • User profile photos
  4. What does the "E" part of PACELC capture that CAP alone doesn't?
    • The cost of encryption
    • That even with no partition, you trade latency for consistency every request
    • Whether the system can scale horizontally
    • Eventually-consistent error rates
  5. Which statement about CAP is *incorrect*?
    • A 3-node etcd cluster with 2 nodes down stops accepting writes — that's CP behaviour
    • AP systems do converge — "eventual" is typically milliseconds, sometimes longer
    • CAP only applies to multi-region deployments; single-region setups are exempt
    • Many real apps mix a CP store (transactional core) with an AP store (read layer)

Related lessons

Programming
intermediate

Distributed Tracing and the Art of Throwing Data Away

Tracing every request through every service produces the most useful telemetry you have and more of it than anyone can afford. This lesson covers how context propagation actually stitches a trace together, the head versus tail sampling decision and why it determines which incidents you can debug, and the collector pipeline where all of it is enforced.

7 steps·~11 min
Programming
advanced

The Failure Modes the Design Creates

Reconciliation buys robustness and charges for it in a specific currency: nothing is ever definitely finished, commands succeed without meaning anything worked, and manual fixes are silently undone. This lesson covers the failures that come from the model rather than from bugs, how to debug them, and when the whole thing is the wrong tool.

8 steps·~12 min
Programming
advanced

Scheduling and Resources: Requests Are Not Limits

Two numbers govern where a pod lands and how it behaves under pressure, and they do completely different jobs. Requests are used for placement and are a promise; limits are enforced at run time and are a ceiling. This lesson separates them, covers the asymmetry between CPU and memory enforcement, and explains what actually happens when a node runs out.

8 steps·~12 min
Programming
advanced

Pods, Services, and the Label That Joins Them

The object types look like an arbitrary vocabulary until you notice they are layers of controllers, each reconciling the one below. This lesson works up from the pod, explains why a Service can point at something whose address changes constantly, and shows that the whole system is joined by one mechanism: a label match.

8 steps·~12 min