CAP Theorem: What It Actually Means for System Design
CAP theorem says you can only pick 2 of 3 properties. But what does that mean in practice? And which systems are CP vs AP vs CA?
CAP Theorem: What It Actually Means for System Design
CAP theorem (Brewer's theorem) states that a distributed data store can only provide two of the following three guarantees simultaneously:
- Consistency — every read receives the most recent write
- Availability — every request receives a response (not an error)
- Partition tolerance — the system continues operating despite network partitions
The critical insight
In a distributed system, network partitions will happen — nodes will lose communication. This means you're not really choosing between C, A, and P. You're choosing between C and A when a partition occurs.
CP Systems (Consistency over Availability)
When a partition occurs, the system refuses to respond rather than risk returning stale data.
Examples: HBase, Zookeeper, etcd, MongoDB (with strong read concern)
Use when: Financial transactions, distributed coordination, anything where stale data is wrong
AP Systems (Availability over Consistency)
When a partition occurs, nodes continue serving requests, but some nodes might return stale data.
Examples: Cassandra, DynamoDB, CouchDB, DNS
Use when: Shopping carts, user preferences, social feeds — stale data is acceptable
CA Systems (Consistency + Availability, no partitions)
These only work on a single node or in a trusted network without partitions. In practice, this means a traditional RDBMS on a single server.
Examples: PostgreSQL, MySQL (single-node)
Interview cheat sheet
| System | Type | Reason |
|---|---|---|
| Cassandra | AP | Eventual consistency by design |
| MongoDB | CP (configurable) | Default write concern gives consistency |
| DynamoDB | AP | Available and eventually consistent |
| PostgreSQL | CA | Single-node consistency, no partitions |
| Zookeeper | CP | Used for distributed coordination |
Beyond CAP: PACELC
CAP only considers partition scenarios. PACELC extends this: even without partitions, you trade latency vs consistency. This is often more relevant in practice.
Related Posts
Microservices Patterns Every Senior Engineer Should Know
Saga, circuit breaker, API gateway, event sourcing — the design patterns that make microservices work at scale and that interviewers ask about.
Redis Caching Patterns Every Backend Engineer Should Know
Cache-aside, write-through, write-behind — different caching strategies have very different consistency guarantees. Know when to use each one.
How to Crack the System Design Interview
Most engineers fail system design interviews not because they lack knowledge, but because they lack a framework. Here's the repeatable 6-step approach that works.