CAP Theorem
What it actually says, why it collapses to one decision in practice, and how that decision shapes your whole design.
Contents
CAP theorem is a routine point of confusion for candidates, yet it’s foundational to how you approach a design. The good news: once you see why partition tolerance isn’t optional, the whole thing collapses into a single, practical question you answer early in every interview.
01What CAP theorem is
At its core, CAP theorem states that in a distributed system you can only have two out of three of the following properties:
Consistency (C) — All nodes see the same data at the same time. After a write to one node, every subsequent read from any node returns that updated value.
Availability (A) — Every request to a non-failing node receives a response, without any guarantee that it holds the most recent version of the data.
Partition tolerance (P) — The system continues to operate despite arbitrary message loss or the failure of part of the system — i.e. network partitions between nodes.
Consistency in the CAP sense is not the consistency guaranteed by ACID databases. They share a word and mean different things. Keep them separate in your head.
Here’s the insight that makes CAP simple to reason about in interviews:
In any distributed system, partition tolerance is a must. Network failures will happen and your system has to handle them — so P is effectively pre-chosen. That means CAP really boils down to a single decision: when a partition occurs, do you prioritize consistency or availability?
A network partition isn’t a node crashing. It’s a communication breakdown between nodes that are both still running but can no longer talk to each other, splitting the system into isolated groups. And it’s not something you can design away — you can’t prevent router crashes or cable cuts — which is exactly why partition tolerance is treated as mandatory. (Note: “partition” here means network partition, not sharding / “failure to shard.”)
02Understanding it through an example
Imagine a website with two servers — one in the USA, one in Europe. When a user updates their public profile (say, their display name):
- User A connects to their closest server (USA) and updates their name.
- That 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 a network partition — the connection between the USA and Europe servers goes down.
The problem bites specifically when the link drops before User A’s update had a chance to replicate to Europe. Now Europe holds an old copy, and the two servers can’t reconcile because they can’t communicate.
When User B tries to view User A’s profile, the system must choose:
Option A · Consistency Return an error — we can’t guarantee the data is current, so we refuse to serve possibly-stale data.
Option B · Availability Show the potentially stale data — serve the old name rather than nothing.
For a public profile, the answer is clear: showing a slightly old name beats showing an error. Seeing a stale name is better than seeing no name at all. But that’s not always the right call — which is the whole point.
03When to choose consistency
Some systems require consistency even at the cost of availability — cases where serving stale data during a partition would be genuinely harmful:
| System | Why consistency wins |
|---|---|
| Ticket / seat booking | If User A books seat 6A but a partition lets User B see it as available and book it too, two people show up for the same seat. |
| E-commerce inventory | One toothbrush left, shown as available to multiple users during a partition → the item gets oversold. |
| Financial systems | Stock platforms need an up-to-date order book; stale prices can cause trades at the wrong price (especially for a low-float stock where a single sale moves the price). |
A rough heuristic several readers use: money or booking involved → consistency; no money changing hands → availability. It’s not a law, but it’s a fast first instinct for the common cases (billing, payments, seat/inventory booking all lean consistency).
04When to choose availability
The majority of systems can tolerate some inconsistency and should prioritize availability. Here eventual consistency is fine — the system becomes consistent, it just might take seconds or minutes.
- Social media — if User A updates their profile picture, it’s fine if User B sees the old one for a few minutes.
- Content platforms (Netflix) — a temporarily stale movie description shown to some users isn’t catastrophic.
- Review sites (Yelp) — briefly outdated restaurant hours beat showing no information at all; you’d rather always display the business.
“Would it be catastrophic if users briefly saw inconsistent data?” If yes → choose consistency. If no → choose availability.
05Using CAP theorem in an interview
CAP should be one of the first things you discuss, because it meaningfully changes your design. A system design interview usually opens by (1) aligning on functional requirements (features), then (2) defining non-functional requirements (system qualities). CAP is where the non-functional phase should start:
“Does this system need to prioritize consistency or availability?” Because P is already chosen for you, this single answer steers the deep dives that follow.
Your answer pulls in a different toolkit:
| If you prioritize Consistency | If you prioritize Availability |
|---|---|
| Distributed transactions — keep multiple stores (e.g. cache + DB) in sync via two-phase commit. Guarantees consistency across nodes but adds complexity and higher latency. | Multiple replicas — scale out read replicas with async replication; reads can be served from any replica even if slightly behind. Better read performance and availability, at the cost of possible staleness. |
| Single-node solutions — one database instance avoids propagation issues entirely; a single source of truth. Limits scalability but eliminates consistency challenges. | Change Data Capture (CDC) — track changes in the primary and propagate them asynchronously to replicas/caches. The primary stays available while updates flow through eventually. |
| Tech: traditional RDBMS (PostgreSQL, MySQL), Google Spanner, DynamoDB in strong-consistency mode. | Tech: Cassandra, DynamoDB in multi-AZ configuration, Redis clusters. |
Choosing consistency doesn’t rule out NoSQL. Many NoSQL databases offer strong-consistency modes — DynamoDB is one. The instructor notes it’s “controversial to some” whether that’s the right choice, but in his opinion it’s totally fine. Also: a single-node choice practically means picking something like Postgres/SQL where you can issue atomic transactions, and accepting higher latency (users may see spinners while propagation completes).
A natural objection: if you go single-node, isn’t the system no longer partition-tolerant / distributed? The reconciliation raised in discussion: “partition” refers to the application servers, while “single node” refers to the database. You can run a distributed set of servers in front of a single strongly-consistent database. The source states this reconciliation but doesn’t deeply derive it — treat it as the intended reading rather than a fully worked-out proof.
Most modern distributed databases can be configured either way. The skill is knowing which to pick for your use case.
06Per-feature trade-offs
For junior / mid-level interviews, the sections above are enough. The instructor explicitly says you can stop there. The following is nuance worth showing at senior level and up.
The choice isn’t always binary for the whole system. Real systems often need both — just for different features.
Example 1 · Ticketmaster
- Booking a seat → consistency, to prevent double-booking.
- Viewing event details (CRUD on events) → availability; a slightly outdated description is acceptable, and it’s better that people can always view the event.
In an interview: “I’ll prioritize consistency for booking transactions but optimize for availability when users are browsing and viewing events.”
Example 2 · Tinder
- Matching → consistency. As the source frames it: if both users swipe right at about the same time, the second swiper should see the match immediately, so you need a consistent view of who has swiped on you.
- Viewing a profile → availability; a slightly outdated profile picture is fine.
Readers pushed back that the matching-needs-consistency framing is “a bit forced.” The consensus in the thread: real Tinder matching is eventually consistent, not strongly consistent, and this is really an interview device — an interviewer might state “matches must show immediately” as a non-functional requirement, which is your cue to treat it as a consistency requirement. So read it as: if the requirement dictates immediate visibility, that’s a consistency signal — not as a claim about how Tinder is actually built.
07Different levels of consistency
When people say “consistency” in a CAP discussion, they almost always mean strong consistency. But consistency is a spectrum, and naming the right level is where you can show senior-level nuance.
Strong consistency — all reads reflect the most recent write. Most expensive for performance; necessary where absolute accuracy is required (e.g. bank balances). This is what “consistency” has meant throughout.
Causal consistency — related events appear in the same order to everyone. Not all users need to see all comments at once, but nobody should ever see a reply appear before the comment it replies to.
Read-your-own-writes — you always see your own updates immediately, though others may briefly see an older version. In the USA/Europe example, User A must see their own name change right away or they’ll think the system is broken — while User B in Europe seeing the old name is still fine.
Eventual consistency — the system becomes consistent over time but may be temporarily inconsistent. The most relaxed level (used in systems like DNS), and exactly what you implicitly choose when you prioritize availability.
“Choosing availability” doesn’t mean “giving up on consistency.” It means accepting eventual consistency — you’re fine with the system taking a while to settle into a consistent state.
08The whole thing in one question
CAP theorem sets the stage for how you approach a design and shouldn’t be overlooked — but it doesn’t need to be complicated. Reduce it to one question:
“Does every read need to read the most recent write?”
Yes → prioritize consistency. No → prioritize availability.
09Active recall
Why does CAP “pick 2 of 3” collapse into a single C-vs-A choice in practice?
Because partition tolerance isn’t optional in a distributed system — network failures will happen and you must handle them, so P is effectively pre-chosen. That leaves only the choice between consistency and availability during a partition.
Precisely what is a network partition — and how is it different from a node failing?
A partition is a communication breakdown between nodes that are both still running but can no longer talk to each other, splitting the system into isolated groups. It’s not a crash. You can’t prevent it (cable cuts, router crashes), which is why P is mandatory. It also has nothing to do with sharding.
In the USA/Europe example, why is the data stale, and what are the two options?
The link drops before User A’s update replicates to Europe, so Europe holds an old copy and can’t reconcile. On User B’s read the system must choose: return an error (prioritizing consistency) or serve the stale data (prioritizing availability). For a public profile, stale beats an error.
Name systems that should choose consistency, and the one question that decides it.
Seat/ticket booking, e-commerce inventory, and financial/trading systems — anywhere stale data would be catastrophic (double-booking, overselling, wrong-price trades). Decision question: “Would it be catastrophic if users briefly saw inconsistent data?” Yes → consistency.
How does the C-vs-A decision change your actual design and tech choices?
Consistency: distributed transactions (two-phase commit), possibly a single-node DB, accept higher latency; tech like PostgreSQL/MySQL, Spanner, or DynamoDB in strong-consistency mode. Availability: multiple async read replicas, CDC for async propagation, eventual consistency; tech like Cassandra, DynamoDB multi-AZ, Redis clusters.
Give a system that needs both C and A — for different features.
Ticketmaster: consistency for booking a seat (no double-booking), availability for viewing/editing event details. Tinder (as an interview device): consistency for matching, availability for viewing/updating profiles. Note the Tinder matching example is contested — real matching is eventually consistent; treat “must show immediately” as an interviewer-supplied consistency requirement.
What does “choosing availability” really mean in terms of consistency levels?
It means accepting eventual consistency — not abandoning consistency, just allowing the system time to settle. The spectrum from strongest to most relaxed: strong → causal → read-your-own-writes → eventual.
10Quick revision
The decision in one flow
Must remember
- Pick 2 of 3 (C, A, P); but P is mandatory, so it’s really C vs A during a partition.
- Partition = nodes alive but can’t communicate (≠ crash, ≠ sharding).
- CAP-consistency ≠ ACID-consistency.
- Decide it in the non-functional requirements phase, before designing.
- Choosing availability = accepting eventual consistency, not abandoning consistency.
- Modern DBs are configurable both ways — the skill is picking correctly per use case, even per feature.
C vs A cheat sheet
| Consistency | Availability | |
|---|---|---|
| Pick when | Stale data is catastrophic | Stale data is tolerable (most systems) |
| Examples | Booking, inventory, finance | Social, Netflix, Yelp |
| Design | Distributed txns, single node, higher latency | Replicas, CDC, eventual consistency |
| Tech | PostgreSQL/MySQL, Spanner, DynamoDB (strong) | Cassandra, DynamoDB (multi-AZ), Redis clusters |
Consistency levels (strong → relaxed)
- Strong — every read = most recent write (bank balances).
- Causal — dependent events stay in order (no reply before its comment).
- Read-your-own-writes — you see your own updates instantly; others may lag.
- Eventual — settles over time (DNS); the default when you pick availability.
Mnemonic
Money / booking involved → consistency. No money changing hands → availability. (A fast first instinct, not a hard rule.)