What is the CAP Theorem and Why Does It Matter?

The CAP Theorem states that when a network partition occurs in a distributed system, you must choose between Consistency (every read receives the most recent write or an error) and Availability (every request receives a response, without guarantee it contains the most recent write). Partition tolerance is not optional because networks fail in production: switches drop packets, cross region links flap, and datacenter connections break.

The practical reality is this: during normal operation without partitions, you trade consistency for latency (PACELC extension). Strong consistency requires coordination like majority quorums or leader leases, adding at least one network round trip to your critical path. Amazon DynamoDB achieves single digit millisecond latencies for eventually consistent reads, but strongly consistent reads add an extra network hop and may become unavailable during partitions.

CAP consistency differs fundamentally from ACID consistency. ACID consistency is about maintaining invariants within a single transaction (like foreign key constraints). CAP consistency is about replica agreement: whether all nodes see the same data at the same time. A database can be ACID compliant but CAP available, accepting that different replicas might temporarily diverge during network failures.

Modern systems like Cassandra and DynamoDB let you tune consistency per request. You might require strong consistency (QUORUM reads and writes) for financial transactions where balances must be correct, while using eventual consistency (ONE replica) for social media timelines where showing a post 500ms late is acceptable. The key is matching consistency guarantees to business requirements rather than applying one model everywhere.

💡 Key Takeaways

•Partition tolerance is mandatory in real systems; the actual choice during partitions is between consistency (linearizable reads) or availability (always respond)

•Strong consistency adds at least 1 network round trip (typically 1 to 5ms within a region, 50 to 150ms cross region) because coordination requires quorum agreement

•PACELC extends CAP: even without partitions (ELSE), you trade latency for consistency; Spanner chooses consistency both times, Dynamo chooses availability then low latency

•CAP consistency means replica agreement across nodes, while ACID consistency means maintaining invariants within a transaction; they address different problems

•Tunable consistency per request lets you apply strong consistency to critical operations (money transfers) and eventual consistency to non critical operations (view counts)

📌 Examples

Amazon DynamoDB Global Tables use AP with last writer wins conflict resolution; cross region replication typically completes in sub second to low seconds, prioritizing availability over consistency

Google Spanner chooses CP, refusing writes when majority quorum is unavailable; a write in a single region takes roughly 1 to 5ms, while cross region writes require 50 to 150ms plus commit wait

Apache Cassandra with replication factor 3 and consistency level QUORUM (read 2, write 2) provides strong consistency if quorums overlap, with median latencies under 10ms but p99 at 10s of milliseconds

A shopping cart system might use eventual consistency for adding items (always available, conflicts merged later) but strong consistency for checkout payment (balance must be accurate)

← Back to CAP Theorem Overview