CAP Theorem

The CAP theorem is the single most-quoted (and most-misquoted) idea in distributed systems interviews. Stating it precisely — and applying it to a real database choice — instantly separates candidates who memorized a slogan from those who understand it.

The core idea

The CAP theorem (Brewer's theorem) says a distributed data store can guarantee at most two of three properties at the same time:

• Consistency (C) — every read sees the most recent write (all nodes agree).
• Availability (A) — every request gets a non-error response (the system stays up).
• Partition tolerance (P) — the system keeps working despite dropped/delayed messages between nodes.

Because real networks will partition, P is not optional. So the practical choice during a partition is C vs A.

Beginner — CP vs AP

• CP systems choose consistency: during a partition they refuse or block requests that can't be made consistent, sacrificing availability. Example: a system that returns an error rather than a possibly-stale value.
• AP systems choose availability: during a partition they keep answering, possibly with stale data, and reconcile later (eventual consistency). Example: a shopping cart that stays writable.

Intermediate — the "two of three" nuance

The famous "pick two" is really "when a partition happens, pick C or A." When there is no partition, a well-built system can offer both strong consistency and availability. CAP is a statement about behavior during partitions, not a permanent cap on features.

Advanced — PACELC and reality

CAP ignores latency. PACELC extends it: if Partition, choose A or C; Else (normal operation), choose Latency or Consistency. Many systems trade a little consistency for lower latency even when healthy. Also, "consistency" here means linearizability (strong), not ACID's C. Real databases are tunable — e.g., Cassandra (AP-leaning) and Dynamo-style stores let you pick per-request consistency levels; systems like HBase or a single-primary SQL lean CP.

Worked example

Two data centers lose the link between them (a partition). A banking ledger must not show two conflicting balances, so it's CP: it rejects writes on the minority side until the link heals — correct but temporarily unavailable there. A social "like" counter is AP: both sides keep accepting likes and merge the counts afterward — always available, briefly inconsistent. Same partition, opposite correct choices, driven by requirements.

When to use

Lean CP when correctness is non-negotiable: payments, inventory, bookings, unique constraints. Lean AP when availability and user experience matter more than momentary accuracy: feeds, likes, presence, product views.

Tricks and mnemonic

Remember "P is mandatory, so it's really C-or-A." And: CP = correct but may go down; AP = always up but may be stale.

Fast revision of the CAP theorem.

• CAP: a distributed store can guarantee at most two of Consistency, Availability, Partition tolerance.
• C = every read sees the latest write; A = every request gets a non-error response; P = works despite dropped messages.
• Networks always partition, so P is mandatory → the real choice is C vs A.
• CP = stays consistent, may reject/block requests (loses availability) during a partition.
• AP = stays available, may serve stale data (eventual consistency).
• PACELC: if Partition → A or C; Else → Latency or Consistency.
• Choose CP for payments/inventory; AP for feeds/likes/presence.

Cover the answer, recall, then check. 8 cards.

Q1. What are the three properties in CAP?
A1. Consistency, Availability, Partition tolerance — at most two guaranteed at once.

Q2. Define consistency in CAP.
A2. Every read returns the most recent write; all nodes agree on the data.

Q3. Define availability in CAP.
A3. Every request receives a non-error response (the system stays responsive).

Q4. Why is partition tolerance effectively mandatory?
A4. Real networks inevitably drop/delay messages, so you must tolerate partitions.

Q5. What does a CP system do during a partition?
A5. Stays consistent by refusing or blocking requests it can't make consistent — sacrificing availability.

Q6. What does an AP system do during a partition?
A6. Stays available, possibly serving stale data, and reconciles later (eventual consistency).

Q7. What does PACELC add to CAP?
A7. Even without a partition (Else), you trade Latency vs Consistency.

Q8. CP or AP for a payment ledger?
A8. CP — correctness must not be sacrificed, even at the cost of availability.

Worked Example

Problem: During a network partition in a distributed database, you must trade off consistency vs availability. Which do you favour for (a) a shopping cart and (b) a stock-trade matching engine?

Solution: The CAP theorem says that when a network Partition happens, a distributed system can preserve either Consistency (every read sees the latest write) or Availability (every request still gets a response) — not both. (Without a partition you can have both.)

(a) Shopping cart → AP (favour availability). Users must keep adding items even if replicas briefly disagree; a temporarily divergent cart can be merged later. Downtime here directly loses sales, so stay available and accept eventual consistency.

(b) Trade matching engine → CP (favour consistency). Executing trades on stale data could double-spend shares or mis-price orders. It is safer to reject/pause writes during the partition than to risk an inconsistent ledger.

Answer: Shopping cart = AP; trade matching = CP.