CAP Theorem

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

Go Deeper

• strong-vs-eventual-consistency — start here if this is new to you
• data-replication
• availability
• consensus-algorithms
• distributed-locking

The Real-World Incident That Made This Famous

CAP theorem was first conjectured by Eric Brewer at the PODC keynote in July 2000 and formally proved by Seth Gilbert and Nancy Lynch at MIT in 2002. But the incident that made CAP real for practitioners was Amazon Web Services' major outage on February 28, 2017. A typo in an S3 command took down a huge portion of the us-east-1 region, affecting thousands of websites and services including Slack, Quora, and Trello.

The S3 outage revealed something fascinating about CAP in practice. S3 was designed for high availability, but its metadata subsystem required strong consistency. When the metadata servers went down, S3 could not serve any requests — not even reads of data that was physically present and intact. The system had chosen CP (consistency + partition tolerance) for its metadata layer, which meant that during the partition event, availability was sacrificed.

Meanwhile, services built on DynamoDB (Amazon's AP system) continued operating. DynamoDB accepts writes even during partial failures, using eventual consistency. Some writes during the outage resulted in temporary inconsistencies that were resolved minutes later, but the service never went down. The contrast was stark: the CP system (S3 metadata) had zero availability during the partition, while the AP system (DynamoDB) maintained full availability with minor consistency delays.

Google Spanner deserves special mention. Spanner claims to be "effectively CA" — consistent and available — by using GPS clocks and atomic clocks (TrueTime) to minimize partition impact. In practice, Spanner is CP: during a real network partition, it will sacrifice availability to maintain consistency. But Google's network is so reliable that partitions are extremely rare, making Spanner "effectively CA" in normal operation.

How Senior Engineers Think About This

The most important thing senior engineers know about CAP: you do not choose once for your entire system. Different parts of your system can make different CAP choices. Your user authentication service should be CP (you never want to authenticate with stale credentials). Your social media feed can be AP (showing a slightly stale feed is better than showing nothing). Your payment processing must be CP (double-charging is unacceptable). Your product catalog can be AP (showing a slightly stale price for a few seconds is tolerable).

The second mental model: CAP is about what happens during network partitions, not during normal operation. During normal operation, you can have all three. The question is: when the network splits (and it will), do you choose to stop serving requests (sacrifice A for C) or do you continue serving potentially stale data (sacrifice C for A)?

Senior engineers also know that CAP is a simplification. The PACELC theorem is more useful in practice: during a Partition, choose between Availability and Consistency. Else (when the system is running normally), choose between Latency and Consistency. This captures the reality that even without partitions, there is a tradeoff between consistency and performance. Strong consistency requires coordination (round trips between replicas), which adds latency. Eventual consistency allows local reads, which is faster.

The real conversation in interviews is not "explain CAP" but "for this specific system, what consistency model would you choose and why?" That requires understanding the business requirements, not just the theory.

Common Interview Mistakes

Mistake 1: Saying you can only have two out of three at all times. CAP applies during network partitions. During normal operation, you can have all three. The theorem says that when a partition occurs, you must choose between C and A.

Mistake 2: Treating it as a binary choice. Real systems exist on a spectrum. You can have tunable consistency (like Cassandra's quorum reads) that lets you adjust the tradeoff per query.

Mistake 3: Not knowing real examples. You should be able to name CP systems (HBase, MongoDB with majority write concern, Google Spanner) and AP systems (Cassandra, DynamoDB, CouchDB) from memory.

Mistake 4: Forgetting about PACELC. Modern interviewers expect you to go beyond CAP. Mention PACELC to show depth: "Even without partitions, there is a latency vs. consistency tradeoff."

Mistake 5: Not connecting CAP to the specific problem. If the interviewer asks you to design a chat application, do not just recite CAP theory. Explain that message delivery should be AP (better to show messages out of order than not at all) but read receipts can be eventually consistent.

Production Checklist

• Document the consistency model for every service in your architecture — make it explicit, not accidental
• For CP systems: implement proper timeout and retry logic so clients handle unavailability gracefully
• For AP systems: design conflict resolution strategies (last-writer-wins, vector clocks, CRDTs) before you need them
• Test partition tolerance: use network fault injection tools (Toxiproxy, tc netem) to simulate partitions in staging
• Monitor replication lag for eventually consistent systems — alert if lag exceeds your staleness tolerance
• Use quorum reads/writes (R + W greater than N) when you need per-request consistency guarantees on an AP system
• Implement read-your-own-writes consistency where users expect to see their own changes immediately
• Design idempotent operations so that retries during partition recovery do not cause duplicate side effects
• For payment and financial systems: always choose CP and design for unavailability with queuing and retry
• Keep your "five nines" math honest: 99.999% uptime = 5.26 minutes of downtime per year — know whether your CAP choice actually achieves this

Read the original source | Content from System-Design-Overview

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).

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.