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.

cap distributed-systems consistency availability

Part of:🏛️System Design Fundamentals

Not signed in — your progress and quiz score won't be saved.

Lesson 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.

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:

Data	Prefer
Account balance, financial transactions	CP — never lie about money
Shopping cart, draft post, user prefs	AP — "slightly stale" is fine, never "unavailable"
Inventory count for a flash sale	CP — overselling is worse than slowness
Like counts, view counters	AP — slightly stale numbers are universal
Critical config (feature flags)	depends — flags off-by-error are usually safer
User-facing reads in social feeds	AP — 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.

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
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
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
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
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

advanced

Failure and Time in Distributed Systems

Distributed systems break in ways single machines don't: nodes crash silently, messages vanish, and clocks lie. Learn the standard failure taxonomy, why a global clock is physically impossible, and how Lamport and vector clocks let you reason about causality without one.

8 steps·~12 min·audio

Programming

advanced

CAP and Consistency Models

CAP is the most misquoted theorem in distributed systems. Get the precise statement, learn why PACELC is more useful in practice, and master the consistency spectrum from linearizability down to eventual consistency — with concrete trade-offs for each level.

7 steps·~11 min·audio

Programming

intermediate

Database Sharding and Replication

Go beyond a single database: learn how read replicas offload query load, how range and hash sharding partition data, why consistent hashing makes rebalancing tractable, and how to pick a shard key that avoids the celebrity problem and cross-shard pain.

8 steps·~12 min·audio

Programming

intermediate

Scaling and Load Balancing

Master the mechanics of scaling distributed systems: when to scale up versus out, why statelessness is the prerequisite for horizontal scale, how L4 and L7 load balancers differ, which balancing algorithm fits which workload, and how to avoid turning your load balancer into the next single point of failure.

8 steps·~12 min·audio