How it works
Consistency in CAP means linearizability: operations behave as if there were one up-to-date copy, respecting real-time order. If a write completes before a read starts, that read must reflect the write or a later one. This is not the same as the C in ACID, which concerns application invariants.
Availability means every request received by a non-failing node eventually completes with a valid operation response. An error or indefinite wait does not satisfy it. This is a formal guarantee, not an uptime percentage or a promise of low latency.
A network partition prevents some nodes from communicating with others, even though both groups may still be running and serving clients. A node generally cannot tell whether its peer has failed or whether messages are just delayed.
Suppose two replicas store x = 0 and lose contact. One accepts a write setting x = 1 and acknowledges success. If the other then receives a read, it cannot both return a guaranteed current value and answer without contacting the first replica. Returning 0 sacrifices linearizability; waiting or rejecting sacrifices availability.
A consistency-first design, often called CP, restricts operations that cannot safely proceed. With three consensus replicas split into groups of two and one, the majority can typically continue after establishing leadership, while the isolated replica cannot independently accept authoritative writes. Linearizable reads also need a safe protocol; reading any replica is not enough.
An availability-first design, often called AP, lets reachable replicas keep answering valid operations without coordinating across the partition. Replicas may diverge, so the design needs explicit versioning, merge rules, or conflict handling afterward. Choose this behavior per operation: stale inventory search may be acceptable while confirming a reservation must require coordination.
A worked example
One seat, three replicas, and a network split
A booking service stores seat A12 in a three-replica consensus group. A partition separates two replicas from the third. The majority side can establish a leader and commit a reservation for Alice. The isolated replica still shows A12 as free, but it must not confirm a reservation for Bob. It rejects or times out booking requests and may serve search results only under an explicit stale-read contract. If both sides confirmed independently, later reconciliation could detect the conflict but could not honor both reservations. The design sacrifices booking availability on the isolated side to protect ownership; search can use a different policy.
Trade-offs to say out loud
- Correctness can require rejecting work
- Protecting a single authoritative value during a partition means some otherwise healthy nodes cannot complete affected operations.
- Continued service can expose divergent state
- Answering independently on both sides can produce stale reads or conflicting writes that the application must handle.
- Conflict repair has domain-specific limits
- Merging independent edits can be reasonable, but merging two successful sales of the same seat cannot restore both promises.
- Coordination affects normal-operation latency
- CAP concerns partitions, but leader communication and quorum protocols also add latency when the network is healthy.
- Consistency and durability are separate
- CAP does not determine whether acknowledged data survives crashes, so persistence and replication acknowledgment policies still need their own explanation.
- Different policies increase operational complexity
- Allowing stale reads for some endpoints while requiring authoritative reads for others demands clear routing, API contracts, and recovery behavior.
When to reach for it
- The design replicates mutable data across regions or failure domains, and the interviewer asks what happens when communication fails.
- An operation enforces a global constraint, such as one active owner, a fixed inventory limit, or an account-wide stream cap.
- Users must continue reading or writing while disconnected, making divergence and later reconciliation part of the product contract.
- You need to explain leader failover, minority-replica behavior, or whether a replica can safely serve a read.
How to bring it up in the interview
- Start with an operation and its invariant, not a database label: “A confirmed seat must have only one owner, so an isolated replica cannot confirm bookings.”
- Draw a concrete partition and walk through one write followed by a read on the other side; interviewers will probe acknowledgments, stale results, and timeouts.
- State exactly which requests continue and which fail, wait, or return explicitly stale data; “the system is CP” is not a complete failure policy.
- Explain recovery after communication returns, including conflict resolution for available writes or safe leader authority and fencing for consistency-first operations.
- Separate CAP from adjacent concerns: expect questions about durability, transaction isolation, replication lag, and latency even when no partition exists.
Common mistakes
- Saying “pick any two of three” without explaining that the consistency-versus-availability conflict arises during a partition.
- Treating partition tolerance as a switch that makes network failures disappear when disabled.
- Equating CAP consistency with ACID consistency, or CAP availability with a service uptime target.
- Assuming a leader or overlapping quorums alone prove linearizability without specifying read, write, and failover protocols.
- Calling eventual consistency automatic conflict resolution or assuming later reconciliation can undo an invalid business promise.
Where it comes up
Interview questions where cap theorem is part of a strong answer, and why.
- Design a distributed key-value storeAvailable writes during partitions require explicit consistency guarantees, conflict handling, and repair after replicas reconnect.
- Design a distributed message log like KafkaReplication acknowledgments and safe failover determine which partitions can continue accepting writes without breaking the log's guarantees.
- Design a distributed cacheReplica failover and ownership changes require a deliberate policy for stale reads and writes when nodes cannot communicate.
- Design Netflix's concurrent screen limitEnforcing an account-wide stream cap during regional isolation requires restricting admission or explicitly allowing temporary excess.
- Design a control plane for a distributed databaseSafe failover requires preserving a single authority despite partitions rather than letting isolated controllers create competing primaries.
- Design a distributed rate limiterA distributed limiter must choose whether partitioned nodes reject traffic or continue admitting requests without an exact global count.
Questions people ask
Does CAP theorem mean you always choose two out of three?
No. When a partition prevents replicas from communicating, you cannot guarantee both linearizability and availability for every request. Without that partition, CAP does not force the same choice, although coordination still has latency and operational costs.
Are SQL databases CP and NoSQL databases AP?
Those categories do not determine CAP behavior. Replication protocols, deployment topology, read settings, and acknowledgment rules determine what happens during a partition. Explain the actual configuration and operation rather than assigning a label based on the data model.
How does CAP theorem relate to eventual consistency?
Eventual consistency promises convergence once updates stop and replicas can exchange the necessary information. It is often used in systems that keep serving during partitions, but CAP does not require any particular convergence mechanism. An AP design still needs explicit rules for conflicting updates and for values exposed before convergence.