What CAP Theorem Says
In a distributed system, you can guarantee only two of the following three:
- Consistency (C)
Every read returns the latest write. - Availability (A)
Every request to a non-failing node gets a response (may be stale). - Partition Tolerance (P)
The system continues to work despite network failures between nodes.
Summary
CAP = you can’t have C + A + P at the same time.
The Key Simplification
Partition tolerance is non-negotiable in real systems. Networks fail.
Important
In practice, CAP reduces to one choice:
When a partition happens, do you choose Consistency or Availability?
Consistency vs ACID (Common Confusion)
- CAP consistency = all nodes see the same data at the same time
- ACID consistency = data obeys rules/constraints within a database
Warning
These are not the same thing. Don’t confuse them in system design.
CAP Through a Simple Example
Scenario:
- two servers: USA and Europe
- user updates profile name in USA
- update replicates to Europe
Normal state:
- both servers show the new name
Network partition:
- USA ↔ Europe link goes down
Decision:
- C: return error (can’t guarantee freshness)
- A: return stale data
Summary
You must choose. There is no “both” during a partition.
In this case, showing an old name is better than showing nothing → Availability wins.
When to Choose Consistency (CP Systems)
Choose Consistency over Availability when stale data is catastrophic.
Examples:
- ticket booking → no double booking
- inventory systems → no overselling
- financial systems → correct balances, prices
Important
If incorrect data causes irreversible damage, choose consistency.
Typical design implications:
- synchronous replication
- distributed transactions
- higher latency
- possible errors during partitions
Common technologies:
- PostgreSQL / MySQL
- Google Spanner
- DynamoDB (strong consistency mode)
When to Choose Availability (AP Systems)
Choose Availability over Consistency when stale data is acceptable.
Examples:
- social media profiles
- content platforms (netflix metadata)
- review sites (yelp hours)
Summary
If stale data is annoying but acceptable, choose availability.
Typical design implications:
- async replication
- read replicas
- eventual consistency
- high uptime
Common technologies:
- Cassandra
- DynamoDB (multi-AZ eventual consistency)
- Redis clusters
The Key Decision Point
Ask yourself:
“Would it be catastrophic if users briefly saw inconsistent data?”
- Yes → choose Consistency
- No → choose Availability
CAP in System Design
Where it fits
System design flow:
- functional requirements
- non-functional requirements
- architecture & components
Important
CAP belongs in non-functional requirements and should come early.
Say explicitly:
“For this system, I’ll prioritize consistency/availability because …”
How CAP Affects Your Design
If you prioritize consistency
You may use:
- single leader / single node
- strong consistency reads
- distributed transactions
- blocking writes during partitions
Trade-offs:
- higher latency
- reduced availability
If you prioritize availability
You may use:
- async replication
- multiple replicas
- CDC pipelines
- eventual consistency
Trade-offs:
- stale reads
- conflict resolution later
Real systems use mixed models
Summary
CAP decisions are often feature-specific, not system-wide.
Example: ticketmaster
- seat booking → consistency
- browsing events → availability
Example: tinder
- matching → consistency
- profile viewing → availability
Design approach:
“I’ll use strong consistency for X, but optimize for availability for Y.”
Levels of Consistency (Advanced but Useful)
| model | meaning | common use |
|---|---|---|
| strong | always latest data | banking |
| causal | related actions ordered | comments after posts |
| read-your-own-writes | users see their updates immediately | social apps |
| eventual | converges over time | DNS, feeds |
Tip
Most “available” systems are eventually consistent.
Common design pitfalls
- saying “we’ll have both consistency and availability”
- ignoring network partitions
- not tying CAP choice to user impact
- over-explaining theory instead of consequences
Warning
CAP is about trade-offs, not definitions.
Final Takeaway
Summary
CAP theorem is simple in system design: partitions will happen. Decide upfront whether your system should fail with errors (consistency) or serve possibly stale data (availability). Let that choice drive every architectural decision that follows.