CAP Theorem Explained Simply — Pick Two (But Not Really)

Everyone gets CAP theorem wrong#

"Consistency, Availability, Partition tolerance — pick two." You've heard it a hundred times. It's on every system design cheat sheet.

It's also misleading.

What CAP actually says#

In a distributed system, when a network partition happens (and it will), you must choose between:

• Consistency (C): Every read gets the most recent write
• Availability (A): Every request gets a response (even if it's stale)

That's it. You're not choosing 2 out of 3. You're choosing between C and A during a partition. When the network is healthy, you can have both.

Partition tolerance isn't optional. In any distributed system, network failures happen. You can't choose to not have partitions. So the real choice is: when things go wrong, do you prefer consistency or availability?

CP: Consistent but sometimes unavailable#

When a partition occurs, the system refuses to respond rather than give stale data.

Examples:

• PostgreSQL with synchronous replication — if the replica is unreachable, writes block
• ZooKeeper — leader election means temporary unavailability during failover
• MongoDB (with majority write concern) — waits for majority acknowledgment

Use when: Financial transactions, inventory counts, anything where stale data causes real harm. If a payment goes through twice because of stale data, that's worse than a brief outage.

AP: Available but sometimes inconsistent#

When a partition occurs, the system continues serving requests but might return stale data.

Examples:

• Cassandra — always writable, eventual consistency across replicas
• DynamoDB — returns data even if not all replicas have synced
• DNS — returns cached records even if they've been updated

Use when: Social media feeds, product catalogs, analytics dashboards. Showing a slightly stale post count is fine. Showing yesterday's analytics is acceptable.

The spectrum, not a binary#

In practice, nobody builds a pure CP or pure AP system. Real systems make different trade-offs for different operations:

A single application often uses both CP and AP patterns for different features.

Beyond CAP: PACELC#

CAP only talks about partition scenarios. PACELC extends it:

When there's a Partition, choose Availability or Consistency. Else (normal operation), choose Latency or Consistency.

This captures the real-world trade-off: even when everything's working, do you prioritize fast responses (serve from the nearest replica) or consistent responses (always read from the leader)?

• PA/EL: Cassandra, DynamoDB — available during partitions, low latency normally
• PC/EC: PostgreSQL — consistent always, at the cost of latency
• PA/EC: Rare but possible — available during partitions, consistent when healthy

How this applies to your architecture#

When you're designing a system on Codelit, think about each database and service:

• Is this service's data critical for correctness? → lean CP
• Is this service user-facing and latency-sensitive? → lean AP
• Can this data be eventually consistent? → AP with conflict resolution

Generate any architecture and click on the database nodes — the audit tool will flag potential consistency issues and suggest the right trade-off for your use case.

The one rule#

Match the consistency model to the business requirement, not the other way around. Don't force strong consistency on a social media feed. Don't accept eventual consistency for bank transfers.

The right answer is always "it depends" — but now you know what it depends on.

---

Explore consistency trade-offs in real architectures: describe your system on Codelit.io and audit each database component.