## What is CAP Theorem?
CAP Theorem states that in a distributed system, you can only guarantee two out of three properties: Consistency, Availability, and Partition Tolerance.
You cannot have all three simultaneously. This fundamental limitation shapes how distributed databases work.
## The Three Properties
**Consistency**: All nodes see the same data at the same time. Read from any server, get the same result.
**Availability**: Every request gets a response (success or failure). The system always works.
**Partition Tolerance**: System continues working even when network failures split servers into isolated groups.
## Why You Cannot Have All Three
Imagine two servers in different cities. Network fails (partition happens). Now they cannot communicate.
**Choose Consistency**: Lock the system until network recovers. Users cannot access data (not available) but when they can, data is consistent.
**Choose Availability**: Both servers keep working independently. Users can access data (available) but servers might have different data (not consistent).
You must choose. There is no way around it.
## Real-World Trade-offs
**Banks (CP - Consistency + Partition Tolerance)**: Your account balance must be accurate. Banks choose consistency over availability. During network issues, you might not access your account temporarily, but your balance will never be wrong.
**Social Media (AP - Availability + Partition Tolerance)**: Instagram chooses availability. During network issues, you might see slightly outdated likes counts or follower numbers. But the app keeps working. Eventual consistency is fine - likes will sync eventually.
**Single-Server Databases (CA - Consistency + Availability)**: Traditional databases on one server are consistent and available. But if that server fails, everything fails. No partition tolerance.
## Common Choices
**SQL Databases** (PostgreSQL, MySQL): Often choose consistency. Guaranteed accurate data, but might reject requests during failures.
**NoSQL Databases** (Cassandra, DynamoDB): Often choose availability. Always operational, but data might be briefly inconsistent across nodes.
**MongoDB, Redis**: Can be configured for different trade-offs depending on your needs.
## Why It Matters for Developers
When choosing a database, understand CAP trade-offs:
- Building a payment system? Choose consistency. Wrong balances are unacceptable.
- Building a social feed? Choose availability. Users prefer slightly stale content over downtime.
- Building analytics? Eventual consistency is fine. Perfect accuracy is not critical.
## The Reality
In practice, partition tolerance is non-negotiable. Networks fail. Servers crash. You need partition tolerance.
So the real choice is **Consistency vs Availability**. Most systems lean toward one but do not completely abandon the other. They find a balance that fits their use case.
## Key Takeaway
CAP Theorem teaches you that trade-offs are unavoidable in distributed systems. Understanding these trade-offs helps you make informed architectural decisions.
There is no perfect database. There are databases optimized for different priorities. Choose based on what matters most for your application.
