CAP Theorem

In a distributed system, you can only guarantee 2 out of 3 properties simultaneously.

The Three Properties

C — Consistency

Every read receives the most recent write or an error. All nodes see the same data at the same time. If it can't guarantee that → return error rather than stale data.

A — Availability

Every request receives a response — but not necessarily the most recent data. System never returns an error. Always responds, even if data might be stale.

P — Partition Tolerance

System continues operating even when network partition occurs (nodes can't communicate with each other).

Why You Can't Have All Three

During a network partition between Node 1 and Node 2: if user writes to Node 1 and reads from Node 2, you must choose:

• Option A: return error to reader (sacrifice Availability) to maintain Consistency → CP achieved
• Option B: return stale data (sacrifice Consistency) to maintain Availability → AP achieved

Why P is Almost Never Sacrificed

Network partitions WILL happen in any distributed system. Sacrificing P means system shuts down entirely during partition — unacceptable. P is mandatory. Real choice is between C and A.

CP vs AP Systems

Database	Type	Why
Zookeeper	CP	Config management needs consistency
HBase	CP	Strong consistency for big data
MongoDB	CP (default)	Primary node writes only
Redis	CP	Single source of truth
Cassandra	AP	Availability over consistency
CouchDB	AP	Eventual consistency model
DynamoDB	AP (tunable)	Can tune consistency level
DNS	AP	Cached (possibly stale) responses

CAP is Not Binary — It's a Spectrum

Modern systems can TUNE the tradeoff. Cassandra consistency levels: ONE (fastest, least consistent) → QUORUM (majority) → ALL (every node, strongly consistent).

PACELC — Extended Model

CAP only talks about behavior during partitions. PACELC extends this: even without partitions there's a tradeoff between Latency and Consistency.

• PAC → during Partition → choose A or C
• ELC → Else (normal operation) → choose Latency or Consistency