The CAP Theorem: Why Consistency is Hard

← Back to Architecture Hub

The CAP Theorem: Why Consistency is Hard

1. The Three Pillars of CAP

C - Consistency: Every user sees the SAME data at the same time. (If I update my profile, my friend in Japan sees the new name INSTANTLY).
A - Availability: Every request gets a response. (The site never says "Server Error").
P - Partition Tolerance: The system continues to work even if the network between Server 1 and Server 2 breaks. The Law: In a worldwide network, Partition events (P) ALWAYS happen. This means you must choose between C or A.

2. Choosing CP (Consistency + Partition)

"I would rather the site be DOWN than show wrong data."

Example: A Bank Database.
If the network between two bank branches breaks, the bank stops the transaction. It refuses to risk "Double-spending" money.
The Verdict: Best for Money, Inventory, and Legal records.

3. Choosing AP (Availability + Partition)

"I would rather show 'Old' data than show an Error page."

Example: Facebook Likes or Netflix Comments.
If the network is broken, Netflix will show you the comments from 5 minutes ago. It's "Old," but the site stays "Available."
The Verdict: Best for Social Media, Analytics, and Media streaming.

4. PACELC: The 2026 Upgrade

The CAP theorem only talks about when things are "Broken." What about when things are "Normal"? PACELC adds: If there is no partition (P), you choose between Latency (L) or Consistency (C).

If you want 100% consistency, your app will be Slower because the servers have to "Talk" and agree before they answer the user.

Frequently Asked Questions

Is any database 100% consistent? SQL databases (PostgreSQL) are designed to be CP (Strong Consistency). NoSQL databases (Cassandra) are designed to be AP (High Availability). This is the single most important technical reason to choose one over the other.

Can I have all 3? NO. It is mathematically impossible in a distributed system. You can get "Close" (like Google Spanner, which uses Atomic Clocks to minimize the gap), but you can never cheat the Law of CAP.

Key Takeaway

CAP is the "Reality Check" of engineering. By mastering the trade-offs of Consistency vs. Availability, you gain the ability to build systems that reflect the physical reality of the network. You graduate from "Hoping for the best" to "Architecting for the Choice."

Part of the Software Architecture Hub — engineering the truth.