The CAP Theorem in Distributed Databases
In distributed databases, network partition failures are inevitable. The CAP Theorem regulates what guarantees your database can provide when machines are disconnected from one another.
Breaking Down CAP properties
To understand the theorem, let us define the three core guarantees: Consistency, Availability, and Partition Tolerance.
Every read operation returns the value of the most recent write, or an error. All nodes in the cluster see the exact same data simultaneously. When data is written to a node, it must propagate to all other nodes before the write is flagged successful.
Every non-failing node returns a response for every request, regardless of its state. The system remains operational at all times. However, availability does not guarantee that the returned data is the most up-to-date write.
The cluster continues to operate despite an arbitrary number of messages being dropped or delayed due to a network communication failure (partition). A distributed database MUST guarantee partition tolerance.
The CAP Venn Diagram
The CAP Theorem states that you can only provide two of three properties simultaneously. Because network partitions (P) are a physical reality of distributed hardware, you must choose between Consistency (CP) or Availability (AP).
Scenario: CabFlow Driver Balance Synchronization
Let us examine a real-world scenario. Driver John has a wallet balance of $100. Our database is distributed across two nodes: Node A (US West) and Node B (US East). Suddenly, a network fiber cuts, creating a Network Partition between US West and US East.
| Database Strategy | Driver Action (US West / Node A) | Passenger Action (US East / Node B) | Result & Behavior | Trade-off details |
|---|---|---|---|---|
| CP (Consistent) | John completes a ride. Node A records balance as $120. | Passenger queries John's balance on Node B. | Node B returns Error (503 Unavailable). | Node B refuses to return stale data ($100) because it cannot sync with Node A. Availability is sacrificed to preserve Consistency. |
| AP (Available) | John completes a ride. Node A records balance as $120. | Passenger queries John's balance on Node B. | Node B returns $100 (Stale Balance). | Node B returns the latest local data immediately to keep the app working. Consistency is sacrificed to preserve Availability. |
| CA (Single-Node Relational) | John completes a ride. Node A records balance as $120. | Passenger completes a ride. Node B records balance as $130. | Split-brain Chaos! | Without partition tolerance, Node B assumes Node A is dead, elects a new local Master, and accepts contradictory writes. Merging data later is nearly impossible. |
Interactive CAP Partition Simulator
Select a database strategy and simulate a network partition between Node A and Node B to see the immediate result:
The RDBMS "CA" Fallacy & Split-Brain Chaos
RDBMS databases are often at the CA side of the triangle. Is this true?
RDBMS databases (like MySQL or PostgreSQL) are commonly labeled as CA systems. However, this is only true in a single-node setup.
Once a database setup expands to multiple nodes via master (write) - slave (read) setups, the system can no longer be CA. A network partition will eventually occur.
If the system cannot recover from network partitions and still attempts to remain "CA", a split-brain scenariooccurs. The disconnected slave partition assumes the master is offline and elects its own master node. Both partitions accept write commands independently, creating conflicting data histories and corrupting the system's overall consistency.
NoSQL CAP Classification
MongoDB forces consistency. In a replica set, there is only one primary node that receives all writes. If the primary node goes offline due to a network partition, secondary nodes stop accepting writes and start electing a new primary. Writes are disabled until the cluster heals, sacrificing availability.
Cassandra operates without a primary node (masterless architecture). Any node accepts writes and reads. In a partition, nodes serve requests locally using stale information, maintaining availability. Once the partition heals, data is synchronized asynchronously (eventual consistency).