CAP theorem — what it actually means for system design

CAP in One Sentence

During a network partition, a distributed system must choose: return potentially stale data (AP) or refuse to respond until consistency is guaranteed (CP). You cannot do both.

The Three Properties

• Consistency (C): every read returns the most recent write or an error
• Availability (A): every request receives a response (not necessarily the latest data)
• Partition Tolerance (P): the system continues operating when network partitions occur

Why P Is Not Optional

Networks fail. Partition tolerance isn't a choice — it's a reality in any distributed system. The real choice is C vs A during a partition.

Real Examples

• CP: HBase, Zookeeper, etcd — refuse writes during partition to maintain consistency. Used for leader election, config stores.
• AP: Cassandra, DynamoDB, CouchDB — return potentially stale data during partition. Used for user profiles, shopping carts.

# Cassandra consistency level controls CAP position:
# QUORUM = strong consistency (closer to CP)
session.execute(query, consistency_level=ConsistencyLevel.QUORUM)
# ONE = high availability (closer to AP)
session.execute(query, consistency_level=ConsistencyLevel.ONE)

In interviews: when someone asks 'is Cassandra CP or AP?' the correct answer is 'it's tunable — closer to AP by default, but you can move toward CP with higher consistency levels.'