CAP & Consistency Tradeoffs

CAP theorem is routinely a point of confusion for candidates, but it is foundational to how you approach your design in an interview.

We’ll explain what it is, how it works, and the practical tradeoffs you need to make when considering CAP theorem during the non-functional requirements phase of a system design interview.

What is CAP Theorem?

At its core, CAP theorem states that in a distributed system, you can only have two out of three of the following properties:

• Consistency: In the formal CAP formulation, C means linearizability — a strong single-register consistency model. Operations behave as if there is one copy of the data, with a total order that matches real time for non-overlapping operations. Colloquially, people say “all nodes see the same data at the same time,” but in interviews you should be precise: when someone says “we chose consistency,” ask what model they mean — linearizable, sequential, causal, eventual, and so on.
• Availability: In the formal sense used in CAP proofs, every request to a non-failing node gets a non-error response. This is related to, but not the same as, “99.99% uptime” in a product SLA. If a system refuses to answer because it cannot guarantee strong consistency across a split, that is sacrificing A in the strict CAP sense — the caller gets an error or timeout instead of a successful response.
• Partition Tolerance: The system continues despite messages being lost between parts of the system. This is not occasional packet loss; it is a split-brain failure where two sides of a cluster cannot both observe the same writes in time to enforce a global strong register. Partitions happen in real networks, and your design must not pretend the network is always fully connected.

Consistency in CAP is not consistency in ACID. The C in ACID means your database moves only between valid states per its constraints. The C in CAP means linearizability under partition. See CAP vs ACID and our dedicated chapter on ACID Transactions.

Here’s the key insight that makes CAP theorem much simpler to reason about in interviews: In any distributed system, partition tolerance is a must. Network failures will happen, and your system needs to handle them.

This means that in practice, CAP theorem really boils down to a single choice: Do you prioritize consistency or availability when a network partition occurs?

Let’s explore what this means through a practical example.

Understanding CAP Theorem Through an Example

Imagine you’re running a website with two servers - one in the USA and one in Europe. When a user updates their public profile (let’s say their display name), here’s what happens:

• User A connects to their closest server (USA) and updates their name
• This update is replicated to the server in Europe
• When User B in Europe views User A’s profile, they see the updated name

Everything works smoothly until we encounter a network partition - the connection between our USA and Europe servers goes down. Now we have a critical decision to make:

When User B tries to view User A’s profile, should we:

• Option A: Return an error because we can’t guarantee the data is up-to-date (choosing consistency)
• Option B: Show potentially stale data (choosing availability)

This is where CAP theorem becomes practical - we must choose between consistency and availability.

In the case, the answer is rather clear: we would rather show a user in Europe the old name of User A, rather than show an error. Seeing a stale name is better than seeing no name at all.

Let’s look at some other real-world examples of this choice:

When to Choose Consistency

Some systems absolutely require consistency, even at the cost of availability:

• Ticket Booking Systems: Imagine if User A booked seat 6A on a flight, but due to a network partition, User B sees the seat as available and books it too. You’d have two people showing up for the same seat!
• E-commerce Inventory: If Amazon has one toothbrush left and the system shows it as available to multiple users during a network partition, they could oversell their inventory.
• Financial Systems: Stock trading platforms need to show accurate, up-to-date order books. Showing stale data could lead to trades at incorrect prices.

When to Choose Availability

The majority of systems can tolerate some inconsistency and should prioritize availability. In these cases, eventual consistency is fine. Meaning, the system will eventually become consistent, but it may take a few seconds or minutes.

• Social Media: If User A updates their profile picture, it’s perfectly fine if User B sees the old picture for a few minutes.
• Content Platforms (like Netflix): If someone updates a movie description, showing the old description temporarily to some users isn’t catastrophic.
• Review Sites (like Yelp): If a restaurant updates their hours, showing slightly outdated information briefly is better than showing no information at all.

The key question to ask yourself is: “Would it be catastrophic if users briefly saw inconsistent data?” If the answer is yes, choose consistency. If not, choose availability.

CAP Theorem in System Design Interviews

Understanding CAP theorem matters because it should be one of the first things you discuss in a system design interview as it will have a meaningful impact on how you design your system.

In a system design interview, you typically begin by:

• Aligning on functional requirements (features)
• Defining non-functional requirements (system qualities)

When discussing non-functional requirements, CAP theorem should be your starting point. You need to ask the all important question: “Does this system need to prioritize consistency or availability?”

If you prioritize consistency, your design might include:

• Distributed Transactions: Ensuring multiple data stores (like cache and database) remain in sync through two-phase commit protocols. This adds complexity but guarantees consistency across all nodes. This means users will likely experience higher latency as the system ensures data is consistent across all nodes.
• Single-Node Solutions: Using a single database instance to avoid propagation issues entirely. While this limits scalability, it eliminates consistency challenges by having a single source of truth.
• Technology Choices: Traditional RDBMSs (PostgreSQL, MySQL)
• Google Spanner
• DynamoDB (in strong consistency mode)

On the other hand, if you prioritize availability, your design can include:

• Multiple Replicas: Scaling to additional read replicas with asynchronous replication, allowing reads to be served from any replica even if it’s slightly behind. This improves read performance and availability at the cost of potential staleness.
• Change Data Capture (CDC): Using CDC to track changes in the primary database and propagate them asynchronously to replicas, caches, and other systems. This allows the primary system to remain available while updates flow through the system eventually.
• Technology Choices: Cassandra
• DynamoDB (in multiple availability zone configuration)
• Redis clusters

Most modern distributed databases offer configuration options for both consistency and availability. The key is understanding which to choose for your use case.

Advanced CAP Theorem Considerations

If you’re a junior or mid-level candidate, the previous sections are sufficient for most interviews. The following section covers more advanced concepts that might be relevant for senior and staff-level discussions.

As systems grow in complexity, the choice between consistency and availability isn’t always binary. Modern distributed systems often require nuanced approaches that vary by feature and use case. Let’s explore these advanced considerations.

Real-world systems frequently need both availability and consistency - just for different features. Let’s look at two examples:

Example 1: Ticketmaster

Ticketmaster needs different consistency models for different features within the same system:

• Booking a seat at an event: Requires strong consistency to prevent double-booking as we discussed in the previous section.
• Viewing event details: Can prioritize availability (showing slightly outdated event descriptions is acceptable)

In an interview, you might say: “For this ticketing system, I’ll prioritize consistency for booking transactions but optimize for availability when users are browsing and viewing events.”

Example 2: Tinder

Similarly, Tinder has mixed requirements:

• Matching: Needs consistency. If both users swipe right at about the same time, they should both see the match immediately.
• Viewing a users profile: Can prioritize availability. Seeing a slightly outdated profile picture is acceptable if a user just updated their image.

In an interview, you might say: “For this dating app, I’ll prioritize consistency for matching but optimize for availability when users are viewing profiles.”

Different Levels of Consistency

When discussing consistency in CAP theorem, people usually mean strong consistency - where all reads reflect the most recent write. However, understanding the spectrum of consistency models can help you make more nuanced design decisions:

Strong Consistency: All reads reflect the most recent write. This is the most expensive consistency model in terms of performance, but is necessary for systems that require absolute accuracy like bank account balances. This is what we have been discussing so far.

Causal Consistency: Related events appear in the same order to all users. This ensures logical ordering of dependent actions, such as ensuring comments on a post must appear after the post itself.

Read-your-own-writes Consistency: Users always see their own updates immediately, though other users might see older versions. This is commonly used in social media platforms where users expect to see their own profile updates right away.

Eventual Consistency: The system will become consistent over time but may temporarily have inconsistencies. This is the most relaxed form of consistency and is often used in systems like DNS where temporary inconsistencies are acceptable. This is the default behavior of most distributed databases and what we are implicitly choosing when we prioritize availability.

PACELC: Beyond the Partition Case

CAP describes what happens when a partition occurs: you must choose between strong consistency (refuse to answer until you know you are correct — availability suffers in the strict sense) or keep answering on both sides (consistency of a strong register model is impossible without merge rules later). Many systems choose CP (etcd/ZooKeeper-style quorum: the minority partition errors) or AP with eventual merge (BASE-style stores).

But real systems are messier than a single global knob:

• Latency is often the user-visible trade-off, not only CAP. Waiting for a quorum across regions costs milliseconds or seconds even when the network is healthy.
• Not one global knob — per-operation, per-entity, leader/follower, read-your-writes, and monotonic reads all coexist in the same product.
• PACELC extends the discussion: if Partitioned (P), choose Availability (A) vs Consistency (C); else (E), choose Latency (L) vs Consistency (C).

In practice, even when there is no partition, you still trade consistency for speed. A read from a follower replica is faster but may be stale. A strongly consistent global read in Spanner waits for clock synchronization. PACELC captures what interviewers often really mean: “What consistency do you need, and what latency are you willing to pay for it — partition or not?”

CAP vs ACID

These acronyms overlap in vocabulary but describe different scopes:

They are not interchangeable. A PostgreSQL transaction can be fully ACID on one node while the cluster as a whole faces CAP trade-offs at the replication layer. Single-database ACID does not automatically give you cross-service business invariants — that is application and distributed-system design.

For the full treatment of atomicity, isolation, durability, and what the database actually enforces, see ACID Transactions.

Interview Questions

Q1: State the CAP theorem in one sentence.

Answer: Under network partition, you cannot have both perfect linearizable consistency and full availability for arbitrary operations on a single register without compromise — degraded behavior, errors, or a weaker consistency model.

Q2: Why is “pick two of CAP” misleading?

Answer: P is not really optional in large distributed systems; real design is tuning along a spectrum (consistency models, timeouts, partial quorum, SLAs), not a single checkbox. PACELC captures the latency trade-off even when there is no partition.

Q3: Does CAP mean you must use NoSQL?

Answer: No — relational databases are often a single-site CP component. Distributed SQL and global systems still face latency and partition trade-offs at the cluster level. CAP is about distributed behavior, not a mandate to abandon SQL.

Conclusion

CAP theorem is important. It sets the stage for how you approach your design in an interview and should not be overlooked.

But it doesn’t need to be complicated. Just ask yourself: “Does every read need to read the most recent write?” If the answer is yes, you need to prioritize consistency. If the answer is no, you can prioritize availability.