Course contentsShow
← Databases & SQL
Lesson 1523 of 1,95314. High Availability and DurabilityFree lesson

The CAP Theorem Trade-offs

Evaluate how consistency, availability, and partition tolerance inform database architecture choices.

In this lesson, you will learn how the CAP theorem forces architects to choose between consistency, availability, and partition tolerance when designing distributed data systems.

The Trilemma of Distributed Systems

The CAP theorem states that in the presence of a network partition—a communication failure between nodes in a distributed system—you must choose between Consistency (C) and Availability (A). You cannot have both.

  • Consistency (C): Every read receives the most recent write or an error.
  • Availability (A): Every request receives a (non-error) response, without the guarantee that it contains the most recent write.
  • Partition Tolerance (P): The system continues to operate despite an arbitrary number of messages being dropped or delayed by the network.

In modern distributed databases, Partition Tolerance (P) is mandatory because network failures are inevitable. Therefore, the real architectural choice is between CP and AP.

Choosing Your Trade-off

If you prioritize CP (Consistency + Partition Tolerance), your database will refuse requests if it cannot guarantee the data is up-to-date across nodes. This is common in financial systems where an incorrect balance is unacceptable.

If you prioritize AP (Availability + Partition Tolerance), your database accepts writes even if nodes are disconnected. This leads to Eventual Consistency, where the system reconciles data conflicts later. This is often preferred for high-traffic social media feeds or shopping carts where user uptime is more critical than immediate global synchronization.

Consider this simplified logic for a write operation in a distributed node:

-- Conceptual CP approach:
IF nodes_reachable == quorum THEN
    COMMIT_WRITE();
ELSE
    RETURN "Error: Consistency not guaranteed";
END IF;

-- Conceptual AP approach:
WRITE_LOCAL();
QUEUE_SYNC_FOR_LATER();
RETURN "Success: Accepted";

Architectural Impact

  • CP Systems (e.g., HBase, MongoDB): Favor strong consistency but sacrifice availability during network issues.
  • AP Systems (e.g., Cassandra, DynamoDB): Favor high availability, allowing systems to remain responsive even during network outages, accepting that users might temporarily read stale data.

Key Takeaway: Because network partitions are unavoidable in distributed systems, you must explicitly trade off between guaranteeing absolute data correctness (CP) and ensuring continuous system responsiveness (AP).