The CAP Theorem

Imagine two copies of your data on two different machines. The wire between them snaps. A user asks a question. You now have two choices: give them an answer that might be wrong, or give them no answer at all. This is exactly the problem the CAP theorem explains.

---

What you will learn

By the end of this post you will understand:

• What Consistency, Availability, and Partition tolerance mean, with everyday analogies.
• The one sentence that states the theorem correctly (most people get it slightly wrong).
• Why the popular "pick 2 of 3" line is misleading, and what the more accurate version is.
• A step-by-step example of what happens during a network split.
• Where real databases like Postgres, Cassandra, DynamoDB, Mongo, and Spanner sit.
• PACELC, eventual consistency, and tunable quorums.

If you remember one sentence, remember this:

When the network breaks, a distributed system has only two choices: it can return the correct data, or it can keep serving requests. It cannot do both.

---

1. Why do we need CAP?

Before CAP makes sense, you need one picture in your head.

A distributed system is just data stored on more than one machine. We copy data across machines (we call this replication) for two important reasons:

• It survives failure. One machine dies, another still has the data.
• It serves more people. Users near London hit the London copy; users near Mumbai hit the Mumbai copy.

So imagine the simplest possible setup: one client (a user, an app) and two database nodes, N1 and N2, that are supposed to be exact copies of each other.

Fullscreen

When everything is working normally, both copies stay in sync. You write to N1, N1 passes the change to N2, and now both copies agree. Read from either one and you get the same answer.

CAP is about what happens when N1 and N2 can no longer communicate.

---

2. The three letters

CAP stands for Consistency, Availability, and Partition tolerance. The names can sound confusing, so let's understand them in simple English.

C: Consistency

Every read sees the most recent write. Ask any copy, get the same, latest truth.

Imagine your bank balance. You spend ₹200 from a ₹500 account. The next time you check, from your phone, an ATM, or the website, it must say ₹300. If one screen says ₹300 and another still says ₹500, the system is inconsistent, and that's a disaster.

Heads up: "Consistency" here is not the C in ACID. We'll untangle that in section 8. It trips up almost everyone.

A: Availability

Every request gets a (non-error) answer, even if some machines are struggling. The system always responds.

Think of a busy shop that never closes. You walk in and you always get served. The price tag might be a bit out of date, but they never shut the door in your face. Availability is about always answering, not about the answer being perfect.

P: Partition tolerance

The system keeps working even when the network between machines breaks and messages get lost.

A partition is when N1 and N2 can no longer talk to each other: a cut cable, an overloaded switch, a cloud zone outage. Picture two people with walkie-talkies who drift out of range: both are alive and listening, but neither can hear the other. Partition tolerance means your system doesn't just crash when this happens. It carries on somehow.

Fullscreen

---

3. What does CAP actually say?

You'll often hear people say:

"Pick any two of Consistency, Availability, Partition tolerance."

It's a handy summary, but it's not quite true. Here's the more accurate version:

In a distributed system, network partitions are not optional; they will happen. So the real choice is only between Consistency and Availability, and you only have to make it during a partition.

The usual "three-way choice" makes it sound like P is a feature you can turn on or off. It isn't. If you have more than one machine, partitions will happen. Cables get cut. Cloud zones go dark. They are a fact of nature, not a design option.

So P is mandatory. That collapses the triangle into a simple either/or that only matters during a partition:

Fullscreen

When the network is healthy, you get both C and A. CAP only matters when a partition happens.

---

4. A worked example

Let's see what happens step by step.

Suppose two database servers, N1 and N2, both store balance = ₹500.

1. A user sends a write to N1: "set balance to ₹300." N1 updates itself.
2. Normally N1 now tells N2. But then the link snaps. A partition. N2 never hears about ₹300.
3. A second later, another request arrives, this time at N2: "what's the balance?"

N2 is stuck. It knows it might be out of date, but it can't reach N1 to check. At this point, it has only two options:

Fullscreen

Those are the only two options:

• Answer anyway with the old ₹500 → you kept Availability, you lost Consistency. This is AP.
• Refuse or stall until the link heals → you kept Consistency, you lost Availability. This is CP.

There is no third option. N2 cannot return the correct ₹300, because it does not have it and cannot reach N1 to get it.

---

5. CP, AP, and CA

People talk about CA, CP, and AP "systems." Let's define each and see which ones exist in the real world.

Fullscreen

CA: Consistent + Available

These systems give correct answers and always answer, as long as the network never breaks. The catch: the only way to guarantee no partition is to not be distributed. A single database on a single machine is CA. The moment you have one node, there's no "between" to partition.

In short: A true distributed "CA system" is basically a myth. Once your data is on more than one machine, partitions can happen, and when they do you end up acting like CP or AP. So "CA" mostly means "a single-node database like Postgres or MySQL."

CP: Consistent + Partition-tolerant

During a partition, a CP system would rather say no than say something wrong. It refuses reads/writes on the side that might be stale, sacrificing availability to protect correctness.

Choose CP when a wrong answer is worse than no answer: banking, payments, inventory, seat booking, anything counting money or scarce items.

AP: Available + Partition-tolerant

During a partition, an AP system keeps answering from whatever copy it can reach, accepting that the data might be slightly old. It heals and reconciles once the link returns.

Choose AP when an unavailable service is worse than a slightly stale one: social feeds, likes/views counts, product catalogs, shopping carts, analytics.

---

6. So which should you pick?

Stop thinking "which database is best" and start thinking "what is worse for my users: a wrong answer, or no answer?"

Takeaway: The CAP choice is really a product decision, not just a technical one. The database can't tell you whether stale data or downtime hurts your users more; only you can. The business need decides whether you give up availability or consistency, and the database just gives you the options.

---

7. CAP is not all-or-nothing in practice

Here's a nuance the textbook triangle hides. The choice between C and A isn't a single switch for the whole company; it's a knob you can turn per feature, even per request.

Eric Brewer (who coined CAP) said as much years later:

"The modern CAP goal should be to maximize combinations of consistency and availability that make sense for the specific application."

A real e-commerce app might be:

• CP for "place order" and "charge card" (never double-charge).
• AP for "show product reviews" and "items you viewed" (stale is fine).

Same company, same partition, different choices for different operations. CAP is a per-operation question, not a one-time decision for the whole system.

---

8. CAP vs ACID

Both use the word "Consistency," and they mean completely different things. This single overlap causes more confusion than the rest of CAP combined.

Remember it this way: CAP's C is about agreement across machines. ACID's C is about rules within one transaction. When someone says "this database is consistent," your first question should be: "…which kind?"

---

9. PACELC

CAP has a blind spot: it only describes what happens during a partition. But your system spends almost all of its life on a healthy network, and it's making trade-offs even then. PACELC fills that gap.

PACELC stands for Partition, Availability, Consistency, Else, Latency, Consistency.

Read it like a sentence:

If (P)artition, choose between (A)vailability and (C)onsistency; (E)lse, when things are normal, choose between (L)atency and (C)onsistency.

Fullscreen

The insight: strong consistency costs latency even on a good day. To guarantee every read is up to date, nodes must coordinate and wait for a majority to agree, and waiting is slow. So an AP database like Cassandra is "PA/EL" (favor availability and low latency), while a strongly consistent one like Spanner is "PC/EC" (favor consistency in both cases, and pay for it in speed).

PACELC simply extends CAP to cover normal operation, not just partitions.

---

10. Eventual consistency and tunable quorums

"AP" sounds scary, like "my data is wrong?!", but it's tamed by a friendly idea: eventual consistency.

Eventual consistency: if writes stop, all copies will eventually agree. You might read stale data for a few milliseconds, but the system always converges back to the truth.

That ₹500 you read during the partition? Once the link heals, N2 learns about the ₹300 and catches up. The window of "wrongness" is usually tiny, and for a like-counter, who cares if it says 999 for half a second?

Put it bluntly: if a like count shows 999 instead of 1,002 for a second, nobody cares. If your bank balance shows ₹999 instead of ₹1,002, you very much care. AP is for the first kind of problem, never the second.

Many modern databases let you tune how strict you want to be, per query, using quorums. With N copies of the data:

• W = how many copies must confirm a write before it counts.
• R = how many copies you read from before you trust the answer.

The magic rule:

If R + W > N, every read is guaranteed to see the latest write (strong consistency). Make R + W ≤ N and you trade some certainty for speed and availability.

Fullscreen

This is why people say Cassandra and DynamoDB are "tunable": you dial the C-vs-A trade-off per request instead of committing once.

---

11. Real database examples

A quick reference. (Reality is fuzzier than any single letter, and many of these are configurable, but this is a useful first map.)

About Spanner: Google sometimes calls it "effectively CA." It hasn't beaten CAP; partitions still force a choice. It just makes partitions so rare (private fiber, atomic clocks) that it can pick C and stay available enough that you barely notice the rare moments it can't. The theorem still holds; Google just made partitions extremely rare.

---

12. Common misconceptions, cleared up

"You always give up one of the three." No. With a healthy network you have all three. You only give up C or A, and only during a partition.

"CA databases are a real distributed option." Not really. If it's distributed, partitions can happen, so you're picking CP or AP. "CA" basically means "single node."

"NoSQL = AP, SQL = CP." Wrong. MongoDB (NoSQL) is CP by default; many SQL systems can be configured either way. The data model and the CAP trade-off are separate questions.

"Eventual consistency means the data is just wrong." No, it means temporarily behind, then guaranteed to converge. For the right use case, that window is invisible.

"Spanner broke CAP." It didn't. It made partitions rare enough to choose strong consistency in practice. The theorem is math; it doesn't bend.

---

13. Interview-ready answers

Short, confident versions for when someone asks across the table:

"State the CAP theorem."

In a distributed system, when a network partition happens, you can guarantee consistency or availability, but not both. Since partitions are unavoidable, the real choice is C vs A during a partition.

"Why can't I have all three?"

When two nodes can't talk, a node receiving a request must either answer with possibly-stale data (available, not consistent) or refuse until it can sync (consistent, not available). There's no way to be both correct and responsive when it physically can't reach the latest data.

"Is Postgres CP, CA, or AP?"

Single-node Postgres is "CA": it isn't distributed, so partitions don't apply. As soon as you add replication or clustering, your real behavior depends on how you configure failover and reads, so you're then making CP/AP trade-offs.

"CAP vs PACELC?"

PACELC extends CAP: during a partition it's A vs C (same as CAP), but else (normal operation) it's latency vs consistency. It captures the everyday cost of strong consistency that CAP ignores.

"Pick a database for a payment system. Why?"

Something CP (strong consistency) like Spanner or a properly configured relational store. A wrong balance or a double-charge is far worse than a brief "try again." I'd never want availability to hand a customer stale money data.

---

14. TL;DR

• A distributed system stores copies of data on multiple machines.
• Sometimes the network between those machines breaks: a partition. This isn't optional; it will happen.
• During a partition you must choose: keep answering with maybe-stale data (AP), or stay correct by refusing/waiting (CP).
• "CA" just means a single, non-distributed database.
• The right choice depends on one question: is a wrong answer or no answer worse for my users?
• PACELC adds the everyday truth: even with no partition, strong consistency costs you latency.
• Eventual consistency and R + W > N quorums let you tune the trade-off per request.

CAP is a design trade-off that every distributed system has to make. Understanding it helps you choose the right database for your application.