CAP Theorem

Complete series on Medium.

Today, we’ll learn about the CAP theorem with simple examples. CAP is one of the most critical concepts in system design. Whether asked directly in interviews or applied in designing systems, you need to think about it at the very start. CAP helps determine the trade-offs that will shape your system’s design.

What is CAP Theorem?

The CAP theorem is a desirable property of distributed systems with replicated data.

• C - Consistency

• A - Availability

• P - Partition Tolerance

These are the three desirable properties of distributed systems, but here’s the catch:
You cannot achieve all three simultaneously.

You can only pick two out of three:

• CA (Consistency + Availability)

• CP (Consistency + Partition Tolerance)

• AP (Availability + Partition Tolerance)

CAP Properties Explained

1. Consistency (C):

If Node B has a = 4, and Node A writes a = 5, then the system ensures all nodes (B and C) have the updated value a = 5.
In short, all nodes must have the same data after a successful write.

2. Availability (A):

All nodes in the system should always respond to queries, whether they succeed or fail in fetching data.
For example, if there are two database nodes (B and C), both should respond to client queries, regardless of whether they return data or not.

3. Partition Tolerance (P):

Partition Tolerance ensures that the system remains operational even when there is a communication break between database nodes.
For example, if Node B cannot replicate data to Node C, both nodes should still be able to respond to queries independently, even though the data might be inconsistent.

Why is CAP (All Three) Not Possible?

To understand this, imagine the following scenario:

• The system must be consistent (same data on all nodes).

• It must be available (all nodes respond).

• It must be partition tolerant (respond even during communication breakage).

If the nodes cannot communicate due to a partition, they cannot ensure consistency. At the same time, if all nodes are required to respond (availability), they might return inconsistent data.
Thus, achieving all three is impossible—one property must be sacrificed.

Trade-Offs: Choosing Two

1. AP (Availability + Partition Tolerance)

• Consistency is sacrificed.

• All nodes respond, but data may be inconsistent.

• Example: DNS systems, where responses are fast, but data consistency isn’t guaranteed.

2. CP (Consistency + Partition Tolerance)

• Availability is sacrificed.

• The system ensures consistency by dropping nodes during a partition.

• Example: Distributed databases like MongoDB, which prioritize consistency over availability during network partitions.

3. CA (Consistency + Availability)

• Partition Tolerance is sacrificed.

• The system ensures consistent data and availability but stops working during a partition.

• Example: Traditional relational databases, where strong consistency and availability are prioritized over partition tolerance.

  

Real-World Scenario

In real-world systems, partition tolerance is non-negotiable because a system that goes down during partitions is not practical. Therefore, we typically trade off either:

1. Consistency (AP systems): Example: Video streaming platforms like Netflix prioritize availability and tolerate data lag.

2. Availability (CP systems): Example: Banking systems prioritize data consistency and tolerate temporary unavailability.

Key Takeaway

Partition tolerance ensures the system stays operational during network failures. When designing a distributed system, always prioritize Partition Tolerance and carefully decide between sacrificing Consistency or Availability based on your use case.