The CAP theorem states that a distributed system can only guarantee two of the following: Consistency, Availability, or Partition Tolerance.
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.
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.
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.
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.
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.
When choosing a database, understand CAP trade-offs:
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.
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.
