CAP Theorem

CAP Theorem (Brewer's Theorem) states that a distributed system can guarantee at most two of three 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.

A — Availability: Every request receives a response (not necessarily the most recent data). The system stays operational.

P — Partition Tolerance: The system continues operating despite network partitions (messages between nodes being lost/delayed).

Why You Must Tolerate Partitions

In any real distributed system, network partitions happen — servers lose connectivity, packets get dropped, data centers become unreachable. You cannot build a practical distributed system that fails entirely on any partition. Therefore, you must choose P, and then decide: C or A.

Real-world choice:
  CP system: consistent but may be unavailable during partition
  AP system: always available but may return stale data during partition

CP Systems

"Return an error rather than return stale data"

Examples: HBase, ZooKeeper, MongoDB (with strong consistency), etcd
Use case: financial transactions, leader election, distributed locks

During partition:
Node A ←✗→ Node B

User writes to Node A
User reads from Node B → returns ERROR (can't guarantee latest write)

AP Systems

"Return possibly stale data rather than refuse to serve"

Examples: CouchDB, Cassandra, DynamoDB, Redis (async replication)
Use case: social feeds, shopping carts, analytics, DNS

During partition:
Node A ←✗→ Node B

User reads from Node B → returns possibly stale data (no error)
Eventually, when partition heals, data converges (eventual consistency)

PACELC — a better model

CAP only addresses behavior during partitions. PACELC (Daniel Abadi, 2012) extends it:

If there is a Partition, choose between Availability and Consistency. Else (normal operation), choose between Latency and Consistency.

System	PA/EL	Meaning
Cassandra	AP / EL	Available + low latency; eventual consistency
PostgreSQL	CP / EC	Consistent always; higher latency
DynamoDB	AP / EL (configurable)	Default eventual consistency; strong consistency option

Consistency Levels

CAP's "consistency" is all-or-nothing. Real systems offer tunable levels:

Level	Meaning
Strong	Read always sees most recent write
Linearizable	Reads/writes appear instantaneous, ordered
Sequential	All nodes see operations in same order
Causal	Causally related operations appear in order
Eventual	All replicas converge given no new writes
Read-your-writes	After writing, you always read your own write

Interview Tips

Don't confuse CAP Consistency with ACID Consistency: CAP C is about distributed agreement; ACID C is about data validity constraints.
Partition Tolerance is non-negotiable in practice — the real choice is CP vs AP.
In system design, use this to justify your database choice: "We need strong consistency for payments, so we use PostgreSQL (CP). For the activity feed, eventual consistency is fine, so we use Cassandra (AP)."

CAP Theorem

CAP Theorem (Brewer's Theorem) states that a distributed system can guarantee at most two of three 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.

A — Availability: Every request receives a response (not necessarily the most recent data). The system stays operational.

P — Partition Tolerance: The system continues operating despite network partitions (messages between nodes being lost/delayed).

Why You Must Tolerate Partitions

Real-world choice:
  CP system: consistent but may be unavailable during partition
  AP system: always available but may return stale data during partition

CP Systems

"Return an error rather than return stale data"

Examples: HBase, ZooKeeper, MongoDB (with strong consistency), etcd
Use case: financial transactions, leader election, distributed locks

During partition:
Node A ←✗→ Node B

User writes to Node A
User reads from Node B → returns ERROR (can't guarantee latest write)

AP Systems

"Return possibly stale data rather than refuse to serve"

Examples: CouchDB, Cassandra, DynamoDB, Redis (async replication)
Use case: social feeds, shopping carts, analytics, DNS

During partition:
Node A ←✗→ Node B

User reads from Node B → returns possibly stale data (no error)
Eventually, when partition heals, data converges (eventual consistency)

PACELC — a better model

CAP only addresses behavior during partitions. PACELC (Daniel Abadi, 2012) extends it:

If there is a Partition, choose between Availability and Consistency. Else (normal operation), choose between Latency and Consistency.

System	PA/EL	Meaning
Cassandra	AP / EL	Available + low latency; eventual consistency
PostgreSQL	CP / EC	Consistent always; higher latency
DynamoDB	AP / EL (configurable)	Default eventual consistency; strong consistency option

Consistency Levels

CAP's "consistency" is all-or-nothing. Real systems offer tunable levels:

Level	Meaning
Strong	Read always sees most recent write
Linearizable	Reads/writes appear instantaneous, ordered
Sequential	All nodes see operations in same order
Causal	Causally related operations appear in order
Eventual	All replicas converge given no new writes
Read-your-writes	After writing, you always read your own write

Interview Tips

Don't confuse CAP Consistency with ACID Consistency: CAP C is about distributed agreement; ACID C is about data validity constraints.
Partition Tolerance is non-negotiable in practice — the real choice is CP vs AP.
In system design, use this to justify your database choice: "We need strong consistency for payments, so we use PostgreSQL (CP). For the activity feed, eventual consistency is fine, so we use Cassandra (AP)."