The CAP Theorem, formulated by Eric Brewer, states that in a distributed database system, you can only guarantee two out of three properties simultaneously: Consistency, Availability, and Partition Tolerance. Consistency means every read receives the most recent write or an error. Availability ensures every request receives a non-error response, even if some nodes are offline. Partition Tolerance means the system continues functioning despite network failures that split nodes into isolated groups. The theorem highlights a fundamental trade-off: when a network partition occurs (e.g., nodes losing connectivity), the system must choose between maintaining consistency or availability. This choice shapes how databases handle failures and data synchronization.
In practice, distributed databases prioritize either Consistency + Partition Tolerance (CP) or Availability + Partition Tolerance (AP). For example, a CP system like MongoDB (when configured for strong consistency) ensures all nodes have the same data during a partition but may become temporarily unavailable if nodes can’t communicate. Conversely, an AP system like Apache Cassandra remains available during partitions, allowing reads and writes even if some nodes are disconnected, but may return stale data until the partition resolves. A purely Consistency + Availability (CA) system is rare because network partitions are inevitable in distributed environments, making Partition Tolerance a practical necessity. Most databases focus on CP or AP, adjusting their behavior dynamically during partitions.
Real-world systems often balance CAP trade-offs through design choices. For instance, many AP databases use eventual consistency, where data converges to a consistent state once communication is restored. Cassandra allows developers to tune consistency levels per query (e.g., requiring responses from a majority of nodes for critical writes). Similarly, CP systems like Google Spanner use synchronized clocks and consensus algorithms to minimize downtime while maintaining consistency. The choice depends on the use case: financial systems prioritize consistency to prevent incorrect balances, while social media platforms might favor availability to ensure users can post even during outages. Developers must evaluate their application’s tolerance for stale data, downtime, and recovery complexity when selecting a database.