CAP Theorem

CAP theorem states that a distributed system can guarantee at most two of three properties: Consistency (every read returns the most recent write), Availability (every request receives a response), and Partition tolerance (the system continues operating despite network failures). Since network partitions are unavoidable in distributed systems, the practical choice is between consistency and availability during a partition — CP or AP.

The Problem CAP Theorem Solves

CAP theorem is the most asked theoretical concept in system design interviews. It defines the fundamental constraint of distributed systems. Understanding it helps you choose the right database, design the right consistency model, and explain tradeoffs to interviewers.

How It Works Under the Hood

The CAP theorem states that a distributed system can provide at most two of three guarantees simultaneously: Consistency (every read receives the most recent write), Availability (every request receives a response), and Partition tolerance (the system continues operating despite network partitions between nodes). Since network partitions are unavoidable in distributed systems, the practical choice is between CP (consistency + partition tolerance) and AP (availability + partition tolerance).

Consider a system with two database nodes, A and B, connected by a network. A user writes data to node A. If the network between A and B is healthy, A replicates to B, and both nodes are consistent. But if the network partitions (A cannot reach B):

• CP choice: Node B stops accepting reads/writes for the affected data until the partition heals. Users may get errors, but they never see stale data.
• AP choice: Node B continues serving requests using its last known data. Users get responses, but the data may be stale. When the partition heals, nodes reconcile (conflict resolution).

In practice, most systems use a spectrum. A banking system uses CP for account balances (correctness is critical). A social media feed uses AP for timeline posts (showing slightly stale posts is acceptable).

The Mental Model

• Partition tolerance is not optional: In any networked system, network failures happen. You must tolerate them. The real choice is between C and A during a partition.
• CP systems (e.g., ZooKeeper, HBase, MongoDB with majority write concern): During a partition, nodes that cannot confirm consistency will refuse requests. The system is correct but may be temporarily unavailable.
• AP systems (e.g., Cassandra, DynamoDB, CouchDB): During a partition, all nodes continue serving requests, but some may return stale data. The system is available but temporarily inconsistent.
• PACELC extension: When there is no Partition, you still choose between Latency and Consistency. Even during normal operation, strong consistency requires coordination that adds latency.
• Tunable consistency: Modern databases like Cassandra let you configure consistency per query — read one replica for speed, or read a quorum for correctness.

Real Systems That Depend on This

Google Spanner achieves strong consistency globally using TrueTime (GPS + atomic clocks) — effectively providing CP with very high availability, but at enormous infrastructure cost.

Amazon DynamoDB defaults to AP (eventually consistent reads) for speed, but offers strongly consistent reads as an option at 2x the cost.

Apache Cassandra is an AP system by default with tunable consistency — you can require quorum writes and reads for stronger guarantees.

Where This Shows Up in Interviews

1. Explain the CAP theorem. Give examples of CP and AP systems.
2. Why can you not have all three of C, A, and P?
3. When would you choose consistency over availability, and vice versa?
4. What is eventual consistency and when is it acceptable?
5. How does Google Spanner seemingly violate the CAP theorem?

Tradeoffs

• Consistency vs. Availability: The core CAP tradeoff — choose based on business requirements. Financial data needs consistency; social feeds can tolerate staleness.
• Latency vs. Consistency: Even without partitions, synchronous replication (strong consistency) adds latency.
• Complexity vs. Correctness: Eventual consistency requires conflict resolution logic (last-writer-wins, vector clocks, CRDTs).

Watch Out For

1. Saying 'we will choose all three' — this is impossible during a network partition
2. Ignoring the PACELC extension — CAP only describes behavior during partitions
3. Treating CAP as a binary choice — modern systems offer tunable consistency
4. Not relating CAP to the specific system being designed in the interview

How to Explain This in an Interview

Here is how I would explain CAP Theorem in a system design interview:

CAP theorem says that during a network partition, you must choose consistency or availability — you cannot have both. CP systems like ZooKeeper reject requests when they cannot guarantee the latest data. AP systems like Cassandra always respond but might return stale data. The key insight for interviews: most real systems are not purely CP or AP — they make different tradeoffs for different operations. A banking system is CP for account balances (you must never show a wrong balance) but AP for transaction history (showing a slightly stale list is acceptable). Always frame your CAP discussion around specific operations and data types, not the entire system as a monolith.

Go Deeper

• strong-vs-eventual-consistency — start here if this is new to you
• Data Replication
• Availability
• consensus-algorithms
• Distributed Locking

CAP Theorem in .NET Database Choices

As a .NET developer, the CAP theorem directly affects your database selection:

CP choice — SQL Server / Azure SQL: Strong consistency with ACID transactions. Use this for financial data, user accounts, inventory management. Entity Framework Core makes this the default path for .NET developers, and it is the right choice for 90 percent of applications.

AP choice — Azure Cosmos DB: Globally distributed with tunable consistency. Cosmos DB offers five consistency levels from Strong to Eventual. The .NET SDK makes it easy to switch:

var cosmosClient = new CosmosClient(endpoint, key, new CosmosClientOptions
    ConsistencyLevel = ConsistencyLevel.Session // or Strong, Eventual, etc.
);

Session consistency (Cosmos DB's default) is the sweet spot for most .NET web applications — you always see your own writes, but other users might see slightly stale data. This works perfectly for shopping carts, user profiles, and social feeds.

Real example: Xbox Live (built on .NET) uses Cosmos DB with session consistency for player profiles and game state. When you update your gamer tag, you see the change immediately, but your friends might see the old name for a few seconds. This tradeoff lets Xbox serve 50+ million active players globally with single-digit millisecond latency.

CAP Theorem in System Design Interviews

Interviewers do not ask you to recite CAP theorem — they test whether you can apply it to real design decisions under pressure. Here is what actually happens in interviews and how to handle it.

How interviewers test CAP knowledge. The most common pattern is indirect: the interviewer asks you to design a system (chat application, payment service, social feed), and at some point asks "what consistency model would you use here?" or "what happens if this database node goes down?" Your answer reveals whether you understand CAP or just memorized the definition.

The 2-minute explanation interviewers want to hear. Practice saying this naturally: "CAP theorem says that during a network partition, a distributed system must choose between consistency and availability. In normal operation, we can have both. For this system, I would choose [CP/AP] because [specific business reason]. For example, our payment service needs CP because processing a payment twice is unacceptable — if a partition occurs, we would rather return an error and retry than risk a double charge. But our news feed can be AP because showing a post from 5 seconds ago instead of 2 seconds ago is invisible to the user."

Common follow-up questions and strong answers:

• "Can you give an example of a system that switches between CP and AP?" Strong answer: "Amazon's shopping cart is AP for adding items (better to accept potentially duplicate items than lose a sale) but payment checkout is CP (must not double-charge)."
• "How would you test partition tolerance?" Strong answer: "Use network fault injection tools like Toxiproxy or Chaos Monkey. Simulate network partitions between database replicas and verify the system behaves according to our chosen model — either returning errors (CP) or serving stale data (AP)."
• "What happens after the partition heals?" Strong answer: "For AP systems, we need a conflict resolution strategy. Options include last-writer-wins (simple but can lose data), vector clocks (tracks causality but adds complexity), or CRDTs (mathematically guaranteed to converge but limited to specific data types)."

The key insight interviewers look for: you do not make one CAP choice for your entire system. Different components have different requirements, and the best candidates explain this naturally.

Common Mistakes When Explaining CAP Theorem

These are the mistakes that make interviewers doubt your understanding, even if you technically know the material.

Mistake 1: Treating CAP as a permanent, system-wide binary choice. CAP applies during network partitions, not at all times. During normal operation, a well-designed system provides all three properties. Saying "our system is CP" without qualifying "during partitions" suggests you think consistency and availability are always in conflict. Additionally, different services within the same system can make different CAP choices.

Mistake 2: Ignoring that network partitions happen in practice. Some candidates hand-wave partitions as rare theoretical events. In reality, a 2011 study by Google found that network partitions occur regularly in their data centers. AWS has had multiple high-profile partition events. If you design a system assuming partitions never happen, you are designing a system that will fail unpredictably in production.

Mistake 3: Confusing consistency models. CAP's "consistency" means linearizability — every read sees the most recent write. This is different from ACID consistency (database invariants are maintained), eventual consistency (replicas converge over time), and causal consistency (causally related operations are seen in order). Conflating these in an interview signals shallow understanding. Be precise about which consistency model you mean.

Mistake 4: Forgetting that availability in CAP means every non-failing node must respond. CAP's definition of availability is strict: every request to a non-failing node must receive a response. A system that routes all traffic to a single primary (and returns errors if the primary is down) is not "available" in the CAP sense, even if it has replicas standing by. This matters because many systems people call "CP" are actually "CP with fast failover."

Mistake 5: Not mentioning PACELC when the interviewer gives you an opening. If the interviewer asks about performance tradeoffs in addition to partition behavior, mentioning PACELC shows depth. PACELC says: during a Partition, choose Availability or Consistency; Else (normal operation), choose Latency or Consistency. This captures the fact that even without partitions, strong consistency requires coordination between replicas, which adds latency. DynamoDB is PA/EL (available during partitions, low latency otherwise), while Google Spanner is PC/EC (consistent during partitions, consistent in normal operation — but at higher latency due to TrueTime synchronization).

Original DosiBridge notes for CAP Theorem

This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study CAP Theorem is to connect the concept to a production service where growth exposes the first weak assumption in the original design. That framing changes the design discussion from definitions to operating choices.

What makes this topic distinct

• SLO: For CAP Theorem, decide the SLO before choosing tools; otherwise the design looks clean but fails when cap changes.
• Capacity Headroom: For CAP Theorem, decide the capacity headroom before choosing tools; otherwise the design looks clean but fails when theorem changes.
• Failure Mode: For CAP Theorem, decide the failure mode before choosing tools; otherwise the design looks clean but fails when cap changes.
• Degradation Path: For CAP Theorem, decide the degradation path before choosing tools; otherwise the design looks clean but fails when theorem changes.
• Operator Signal: For CAP Theorem, decide the operator signal before choosing tools; otherwise the design looks clean but fails when cap changes.

Production review question

If a team adopts CAP Theorem, what observable signal proves it helped instead of only making the architecture diagram more fashionable?

Practical metric to track

Track cap-theorem health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For CAP Theorem, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.

Frequently Asked Questions About CAP Theorem

Is CAP theorem still relevant in 2025, or has it been superseded? CAP theorem is absolutely still relevant as a foundational mental model. However, it has been refined. Eric Brewer himself wrote a 2012 retrospective acknowledging that CAP is often misunderstood as a simple "pick two" choice. Modern thinking uses PACELC for a more complete picture, and recognizes that consistency and availability exist on a spectrum (tunable consistency in Cassandra, five consistency levels in Cosmos DB). You should understand CAP as the starting point and PACELC as the more practical framework.

Can a system be both CP and AP simultaneously? No, not during a network partition — that is precisely what CAP proves. However, a system can be CP for some operations and AP for others. Amazon's platform is the classic example: the shopping cart is AP (always accept items, resolve conflicts later) while the order processing pipeline is CP (never process a duplicate or inconsistent order). Within a single database, Cassandra lets you choose consistency level per query: a quorum read is CP-like, while a single-replica read is AP-like.

What is PACELC and why should I know it? PACELC extends CAP to cover normal (non-partition) operation. It stands for: during a Partition, choose Availability or Consistency; Else, choose Latency or Consistency. This matters because most of the time your system is not partitioned, and you still face a tradeoff between response speed (latency) and data freshness (consistency). For example, DynamoDB is classified as PA/EL: during partitions it prioritizes availability, and during normal operation it prioritizes low latency (eventually consistent reads are half the cost and faster than strongly consistent reads).

How does CAP theorem apply to microservices architectures? In a microservices architecture, each service can make independent CAP choices based on its domain requirements. The user authentication service should be CP (never authenticate with stale credentials). The recommendation engine can be AP (showing slightly outdated recommendations is fine). The challenge is at service boundaries: if service A (CP) depends on service B (AP), the overall consistency guarantee is only as strong as the weakest link. This is why distributed sagas and eventual consistency patterns (like the outbox pattern) are critical in microservices — they let you maintain cross-service consistency without requiring distributed transactions.

What consistency model does DynamoDB use? DynamoDB defaults to eventually consistent reads, which means a read might not reflect the result of a recently completed write. This is the AP choice — you get lower latency and higher throughput. However, DynamoDB also supports strongly consistent reads on a per-request basis, at double the read capacity cost and slightly higher latency. The strongly consistent option reads from the leader replica, guaranteeing you see the latest write. For the DynamoDB Global Tables feature (multi-region replication), only eventually consistent reads are supported across regions, because cross-region strong consistency would add hundreds of milliseconds of latency per read.