Why CAP keeps confusing people
CAP theorem is routinely a point of confusion for candidates, but it is foundational to how you approach design in an interview. We’ll cover what it is, how it works, and the practical tradeoffs you make when you raise it in the non-functional requirements phase.
C, A, P — and how C ≠ ACID.
USA ↔ Europe profile update.
Tickets/money → C; feeds → A.
Open NFRs with C vs A; mix by feature.
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 — All nodes see the same data at the same time. When a write is made to one node, subsequent reads from any node return that updated value.
- Availability — Every request to a non-failing node receives a response, without the guarantee that it contains the most recent version of the data.
- Partition tolerance — The system continues to operate despite arbitrary message loss or failure of part of the system (network partitions between nodes).
Here’s the insight that makes CAP much simpler in interviews: in any distributed system, partition tolerance is a must. Network failures will happen, and your system needs to handle them. That means CAP really boils down to a single choice: do you prioritize consistency or availability when a network partition occurs?
Understanding CAP through an example
Imagine a website with two servers — one in the USA and one in Europe. When a user updates their public profile (display name), here’s the happy path:
- User A connects to their closest server (USA) and updates their name.
- The 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 until a network partition: the connection between USA and Europe goes down. Now you have a critical decision when User B tries to view User A’s profile:
- Option A — Consistency: Return an error because you can’t guarantee the data is up-to-date.
- Option B — Availability: Show potentially stale data.
For a display name, the answer is usually clear: you’d rather show a user in Europe the old name than show an error. Seeing a stale name is better than seeing no name at all.
When to choose consistency
Some systems absolutely require consistency, even at the cost of availability:
- Ticket booking — If User A booked seat 6A but a partition lets User B see it as free and book it too, two people show up for one seat.
- E-commerce inventory — One toothbrush left; during a partition multiple users see “in stock” and you oversell.
- Financial systems — Trading platforms need accurate order books. Stale prices mean trades at the wrong price.
When to choose availability
Most systems can tolerate some inconsistency and should prioritize availability. In these cases eventual consistency is fine: the system becomes consistent over seconds or minutes, not instantly.
- Social media — If User A updates a profile picture, it’s fine if User B sees the old one for a few minutes.
- Content platforms — An outdated movie description briefly isn’t catastrophic.
- Review / local listings — Slightly outdated restaurant hours beat showing no information at all.
CAP in system design interviews
CAP matters because it should be one of the first things you discuss in a system design interview — it shapes the rest of the design.
You typically begin by aligning on functional requirements (features), then defining non-functional requirements (system qualities). When discussing NFRs, CAP should be near the top. Ask: does this system need to prioritize consistency or availability?
If you prioritize consistency
Your design might include:
- Distributed transactions — Keep stores in sync (e.g. two-phase commit). Adds complexity and usually higher latency.
- Single-node / single primary for critical data — Avoids multi-primary propagation issues; limits scale but gives one source of truth.
- Technology examples — Traditional RDBMSs (PostgreSQL, MySQL); Google Spanner; DynamoDB in strong consistency mode.
If you prioritize availability
Your design can include:
- Multiple replicas — Async replication; serve reads from any replica even if slightly behind.
- Change data capture (CDC) — Propagate changes asynchronously to replicas, caches, and other systems while the primary stays available.
- Technology examples — Cassandra; DynamoDB across multiple AZs with relaxed consistency settings; Redis clusters.
Most modern distributed databases offer knobs for both. The skill is knowing which knob to turn for which data. Deeper model names (linearizability, RYW, etc.) live in consistency models.
Advanced considerations
For junior or mid-level interviews, the sections above are enough. The rest is for senior and staff discussions — when the choice isn’t binary for the whole product.
Mixed requirements by feature
Real systems often need both — for different features.
Ticketing: Booking a seat needs strong consistency to prevent double-booking. Viewing event details can prioritize availability (a slightly outdated description is fine).
Dating / matching apps: Matching needs consistency so simultaneous right-swipes both see the match. Viewing a profile can prioritize availability — a slightly outdated photo is acceptable.
Different levels of consistency
When people say “consistency” in CAP, they usually mean strong consistency — all reads reflect the most recent write. The spectrum is wider:
- Strong consistency — All reads reflect the most recent write. Expensive; needed for balances and inventory.
- Causal consistency — Related events appear in the same order to all users (e.g. comments after the post they reply to).
- Read-your-own-writes — Users always see their own updates immediately; others may lag. Common for profiles and carts.
- Eventual consistency — The system converges over time. Most relaxed; default when you prioritize availability (DNS is a classic example).
CAP in product language
Modern nuance
Most cloud databases offer tunable consistency (DynamoDB consistent read, Cassandra quorum, Cosmos levels). Interview win: "For this operation I'd choose quorum/strong; for that one, eventual."
Failure modes to mention
Call out at least one dependency failure (DB down, cache stampede, queue lag, region outage) and your mitigation (timeouts, retries with jitter, degraded mode, circuit breaker).
Cost and performance levers
Interview Q&A by level
Practice saying these out loud for CAP theorem. Interviewers grade clarity and judgment more than buzzwords.
Match depth to the bar: define → trade off → operate. Don't dump principal answers in an entry-level screen.
Wrapping up
CAP sets the stage for how you approach design in an interview — don’t overlook it. It doesn’t need to be complicated.
- Ask: Does every read need the most recent write?
- Yes → prioritize consistency. No → prioritize availability.
- Split by feature when the product isn’t one-size-fits-all.
- Then pick stores, replication, and latency budgets that match.
Next: name the anomalies you’re willing to tolerate in consistency models. For how this fits the interview arc, see how to approach.