CAP Theorem

Overview

The CAP theorem states that a distributed data store can only guarantee two of three properties at once: Consistency (every read sees the latest write), Availability (every request gets a non-error response), and Partition tolerance (the system keeps working when the network drops messages between nodes). Because network partitions are unavoidable in real systems, partition tolerance is effectively mandatory. That means the practical choice under a partition is between consistency and availability.

Syntax / Usage

When nodes can't talk to each other, you must decide what a node does with an incoming request. A CP system refuses or blocks the request to avoid returning stale data. An AP system answers anyway, accepting that different nodes may temporarily disagree.

        Network partition splits nodes A and B
        Client writes X=2 to A (was X=1)

CP choice:  B receives read of X
            --> reject / block until partition heals (stays consistent)

AP choice:  B receives read of X
            --> return X=1 (stale) so it stays available

In normal operation (no partition) systems can be both consistent and available; CAP only forces a choice during failures. Related nuance: the PACELC extension adds that Even when there's no partition (E), you still trade Latency against Consistency.

Examples

A bank ledger favors CP: during a partition it is safer to reject a transfer than to allow two conflicting balances. ZooKeeper and etcd behave this way, refusing writes without a quorum.

A shopping cart favors AP: Amazon's Dynamo-style stores accept writes on any reachable node and reconcile conflicts later, so users can always add items. DynamoDB and Cassandra default toward availability.

A DNS system is heavily AP: resolvers return possibly stale records rather than failing, trading strict freshness for near-constant uptime.

Common Mistakes

• Thinking you must permanently pick two letters, rather than choosing only during a partition
• Treating partition tolerance as optional in a multi-node system
• Assuming "eventually consistent" means data is unreliable, when it usually converges in milliseconds
• Ignoring PACELC's latency-vs-consistency trade-off that applies even without partitions
• Labeling a single-node database as "CA" as if CAP had been beaten

See Also

system-design-databases system-design-scalability system-design-database-sharding