CAP Theorem

A statement about distributed systems with replicated state. Given three desirable properties (Consistency, where every read sees the latest write; Availability, where every request gets a non-error response; and Partition tolerance, where the system keeps working despite network splits), you can guarantee at most two at the same time. Since partitions WILL happen in any real distributed system, the real choice is between C and A when a partition occurs.

Forces an honest conversation about what your system should do when a network split occurs. There's no magic. Either you refuse writes on one side of the partition (CP, choosing consistency) or you accept divergent writes you'll have to reconcile later (AP, choosing availability). Pretending you have all three is a recipe for surprise outages or silent data corruption.

CAP isn't an algorithm; it's a constraint, so here's what the choice looks like in practice. A leader-based distributed store like etcd or ZooKeeper is CP: if the leader is unreachable, writes fail rather than diverge. Spanner is also CP in the strict sense, but its global Paxos + TrueTime infrastructure makes the unavailable windows so short that most apps treat it as 'C with effectively high A'. An eventually-consistent system (Cassandra at default consistency, Dynamo) is AP: writes succeed on whichever replica is reachable; reads may show stale data until convergence. (Single-node Postgres isn't really in scope here, since without replication there's no partition to choose against.)

• Forces explicit choices about consistency vs availability
• Names the tradeoff clearly: no architecture can promise all three under partition

• Often misunderstood, since CAP applies only during partitions, not normal operation
• Most systems are tunable (per-query, per-table), and CAP is a binary that doesn't capture this nuance
• PACELC is a more complete framing: it adds 'when there's no partition, choose Latency or Consistency'

• WhatsApp →

  Cassandra for the message store is AP: during a partition, writes succeed on the reachable replicas; reads may briefly miss recent messages on a recovering node

• Payment Gateway →

  Postgres ledger is CP: money writes through a single primary, so partition means no writes (the alternative, divergent ledgers, is worse than downtime)

• Distributed Cache →

  Caches are typically AP: under partition you'd rather serve a slightly stale value than fail the read

• CAP only applies during a partition. The rest of the time you can have all three, since partitions are the edge case the theorem is talking about.
• PACELC is the better framing: even without a partition, you trade Latency for Consistency (sync replication vs async).
• 'CA' systems don't exist in distributed systems, because partitions are inevitable. Anything claiming CA is really CP that hasn't been tested under partition.
• Per-query tunability (Cassandra's consistency levels, DynamoDB's strongly-consistent reads) means most real systems aren't purely C or A; they're configurable per access.