System Designer
Back to Reference

CAP Theorem

Consistency, availability, and partition tolerance trade-offs

Not Started
Loading...

The CAP theorem states that distributed systems can guarantee only two of three properties: Consistency (all nodes see the same data), Availability (system remains operational), and Partition tolerance (system continues despite network failures). Since network partitions are inevitable in distributed systems, the real choice is between consistency and availability.

The practical insight: choose CP for correctness, AP for resilience. Banking systems choose CP—better to reject transactions than process them incorrectly. Social networks choose AP—better to show slightly stale feeds than no feeds at all. Modern systems like DynamoDB offer tunable consistency, letting you choose per operation.

CAP Theorem Trade-offs

Consistency, Availability, and Partition tolerance in distributed systems

The Three Properties
Consistency (C)
• All nodes see the same data at the same time
• Every read receives the most recent write
• Strong guarantees about data state
Availability (A)
• System remains operational
• Every request gets a response
• No single point of failure
Partition Tolerance (P)
• System continues despite network failures
• Nodes can't communicate but stay running
• Essential for distributed systems
Why You Can Only Pick Two
During a network partition: Nodes can't communicate to coordinate state.
Choose Consistency (CP)
• Reject requests that could cause inconsistency
• System becomes unavailable until partition heals
• Example: Banking - can't risk inconsistent balances
Choose Availability (AP)
• Continue serving requests with potentially stale data
• Accept temporary inconsistency
• Example: Social media - better to show old posts than no posts
Real-world Database Choices
MongoDBCP
Primary fails → reads/writes block until new primary elected
Consistency over availability
CassandraAP
Node fails → system continues, may return stale data
Availability over consistency
PostgreSQLCA
Single node, ACID guarantees, no partition tolerance
Traditional RDBMS
DynamoDBAP (tunable)
Eventually consistent by default, strong consistency available
Configurable trade-offs
Consistency Models Spectrum
Strong Consistency
All nodes see same data at same time
Example: Banking transactions
High Latency
Eventual Consistency
Nodes will converge eventually
Example: Social media feeds
Low Latency
Causal Consistency
Causally related operations are seen in order
Example: Comment after post
Medium Latency
Session Consistency
Client sees consistent view within session
Example: Shopping cart
Medium Latency
Performance Impact of Consistency
Read Latency
1 mseventual
15 msstrong
Write Latency
5 mseventual
50 msstrong
Throughput
100000 ops/seventual
10000 ops/sstrong
Stronger consistency requires coordination • Coordination adds latency and reduces throughput
Practical Design Guidelines
Choose CP When
  • • Financial transactions
  • • Inventory management
  • • User authentication
  • • Data corruption is unacceptable
  • • Regulatory compliance required
Choose AP When
  • • Social media feeds
  • • Content delivery
  • • Analytics and logging
  • • User experience is priority
  • • Eventual consistency is acceptable

📝 Test Your Knowledge

6 questions • Progress: 0/6