The CAP Theorem: Consistency, Availability, and Partition Tolerance
Master the CAP theorem, the fundamental tradeoff in distributed database design, and see how real-world systems choose.
Deconstructing CAP
Formulated by Eric Brewer, the CAP Theorem asserts that a distributed system can guarantee at most two out of three characteristics:
• Consistency (C): Every read receives the most recent write or an error. • Availability (A): Every non-failing node returns a non-error response (without guarantee that it contains the absolute latest write). • Partition Tolerance (P): The system continues to function despite any number of network failures/partitions.
The Partition Dilemma
Network partitions (P) are inevitable in real-world distributed networks. Thus, when a partition occurs, system designers must choose between:
- Consistency (CP): Reject writes or delay reads to ensure all nodes match, sacrificing Availability.
- Availability (AP): Allow writes and reads on available nodes, resulting in stale data (eventual consistency), sacrificing Consistency.
Understanding database trade-offs is crucial when building applications that require horizontal scaling.
Real-World Database Categorizations
• CP Systems: MongoDB, Redis, Apache HBase. They prioritize consistency; a network split makes some nodes unavailable for updates. • AP Systems: Apache Cassandra, AWS DynamoDB, CouchDB. They accept updates on any node and reconcile differences later (e.g., using Vector Clocks). • CA Systems: Traditional SQL databases (PostgreSQL, MySQL) running on a single instance. In a network setting, partition tolerance must be assumed, meaning CA distributed databases are not physically viable.