CAP Theorem

When a distributed system is cut in half by a network partition, it must choose between answering and risking disagreement, or stopping until agreement is safe.

The promise

CAP is not a slogan that says "pick two forever." It is a failure-mode theorem. It asks what a replicated system does when the network stops carrying messages between replicas.

The practical version:

Letter	Meaning	Engineering question
C	Consistency	After a write succeeds, do all later reads see that write?
A	Availability	Does every request to a non-failed node receive a response?
P	Partition tolerance	Can the system keep operating despite lost or delayed network messages?

In real networks, partitions are not optional. Links fail, packets drop, clocks drift, routers flap, cloud zones isolate, deploys wedge service discovery. So the choice under pressure is usually CP or AP.

The system before failure

Imagine a replicated profile service. Two regions hold the same user record. Clients can read from either region. Writes replicate across the network.

When the link is healthy, the system can often give you all three properties in ordinary operation: reads return, writes replicate, and both regions converge on the same value.

CAP becomes interesting only when the replication link breaks.

The partition moment

A partition is not necessarily a machine crash. Both machines may be healthy. The trouble is that they cannot talk to each other.

At this exact point, eu-west has a local copy that still says 100. If it answers 100, the system stays available but may violate consistency. If it refuses to answer until it can contact us-east, the system protects consistency but gives up availability for that request.

The fork in the road

During a partition, a replicated system has two honest choices.

The sharp lesson: CAP is not about what your system says on a sunny day. It is about the behavior you choose when the replicas disagree or cannot communicate.

CP systems

CP systems preserve a single agreed value during partitions. If they cannot prove a write or read is safe, they refuse it, wait, or redirect to a leader.

Common CP behavior:

Behavior	Why it protects consistency	Cost
Leader-only writes	One authority orders changes	Leader loss hurts availability
Majority quorum	A value is accepted only by enough replicas	Minority partition cannot serve writes
Linearizable reads	Reads confirm the latest committed value	Higher latency and possible read failures
Fencing tokens	Old leaders cannot keep mutating state	More coordination machinery

Examples that lean CP: ZooKeeper, etcd, Consul, Spanner-style strongly consistent databases, many SQL systems configured for synchronous replication.

Use CP when the wrong answer is worse than no answer: bank transfers, inventory reservation, identity and permissions, distributed locks, schema migrations, leader election, billing mutations.

AP systems

AP systems keep answering during partitions. They accept that replicas may temporarily disagree, then repair the disagreement later.

Common AP behavior:

Behavior	Why it protects availability	Cost
Local reads and writes	Nearby replicas can answer without coordination	Stale reads are possible
Async replication	Writes do not wait for every region	Lag creates divergent copies
Conflict resolution	System can merge later	Business rules get harder
Idempotent events	Replays and duplicates are survivable	More careful API design

Examples that lean AP: Dynamo-style key-value stores, Cassandra-style systems, shopping carts, feeds, counters with merge logic, telemetry ingestion, logs, recommendation events.

Use AP when no answer is worse than a temporarily imperfect answer: likes, analytics events, shopping carts, presence, recommendations, feeds, sensor data, non-critical user preferences.

Why "pick two" misleads

The common triangle is useful as a doorway, then harmful as a map.

Modern systems are not one CAP point. A product may choose CP for account balances, AP for notification counters, and eventual consistency for profile search. The boundary is per workflow, per data type, and per failure mode.

A concrete example: checkout

Suppose an item has one unit left in stock, replicated across two regions.

If Region B confirms the second order, availability is high but the store oversells. If Region B blocks, consistency is protected but the customer sees an error or delay.

For checkout inventory, CP is often the safer default. For adding that item to a cart, AP is usually fine because conflicts can be resolved before payment.

Decision checklist

Use this checklist when designing a feature:

Question	If yes, lean
Can a stale answer cause money loss, security risk, or legal trouble?	CP
Can the user retry safely after an error?	CP
Is no response worse than a slightly stale response?	AP
Can two concurrent updates be merged automatically?	AP
Is this a derived view, cache, feed, metric, or notification count?	AP
Is this an authority record, lock, permission, or scarce resource?	CP

Visual memory

Hold CAP in your head as one picture:

                network partition
          +----------------------------+
          | replicas cannot coordinate |
          +-------------+--------------+
                        |
             what do you sacrifice?
                        |
          +-------------+--------------+
          |                            |
   availability                  consistency
   answer locally                wait for proof
   reconcile later               fail or block now
          |                            |
          v                            v
         AP                           CP

Interview answer

A strong system-design answer does not recite "C, A, P, pick two." It says:

Partitions are unavoidable in distributed systems.
During a partition, each operation must choose between answering locally and preserving a single agreed value.
If stale or conflicting data is dangerous, choose CP behavior.
If temporary divergence is acceptable and repairable, choose AP behavior.
Many real products mix both choices across different workflows.

Key takeaways

CAP is a partition-time theorem, not a general database ranking.
Because partitions happen, the real choice is usually CP versus AP.
CP sacrifices availability to protect one agreed value.
AP sacrifices immediate consistency to keep serving requests.
Design the tradeoff per operation, not per brand name or whole system.