CAP Theorem

When the network breaks, you must choose: serve stale data or refuse to serve. You cannot guarantee both.

Imagine two bank branches in the same city. They share one customer account — a joint account with $1,000 in it. On a normal day, every time someone withdraws money at Branch A, the system instantly tells Branch B the new balance. Everything stays in sync. Life is good.

Now imagine the phone line between the branches goes dead. At that exact moment, a person walks into Branch A and withdraws $800. The balance should be $200. But Branch B doesn't know that — it still thinks the balance is $1,000. Seconds later, someone walks into Branch B and tries to withdraw $500.

Branch B has a choice, and only two options exist:

Option A — Stay available: Branch B checks its own records, sees $1,000, and hands over $500. The customer walks out happy. But now the real balance is negative $300. The bank just lost money because it served stale data. The system was availableIn CAP terms, "available" means every request gets a response — the system never says "come back later." It might give you slightly outdated data, but it always answers. (it answered the request) but inconsistentInconsistency means different parts of the system disagree about the current state. Branch A says the balance is $200, Branch B says $500. Both are "correct" from their own perspective, but they can't both be right. (the answer was wrong).

Option B — Stay consistent: Branch B says "Sorry, our systems are temporarily down. I can't process withdrawals right now." The customer is frustrated and walks out. But the bank's books are still accurate — nobody got money they shouldn't have. The system was consistentIn CAP terms, "consistent" means every read returns the most recent write. If Branch A accepted a withdrawal, Branch B must know about it before serving any requests. All nodes agree on the current state. (correct data) but unavailableUnavailable doesn't mean the server is crashed — it means the server deliberately refuses to answer because it can't guarantee correctness. It's a conscious choice to protect data integrity. (it refused the request).

There is no Option C. Branch B cannot magically know about the $800 withdrawal — the phone line is dead. It can either guess (and risk being wrong) or refuse (and risk frustrating the customer). That's the entire CAP theoremProposed by Eric Brewer in 2000 and formally proven by Seth Gilbert and Nancy Lynch in 2002. It states that a distributed system can provide at most two out of three guarantees: Consistency, Availability, and Partition tolerance. in one story.

This isn't some edge case that only happens at Google scale. If you have any data that lives on more than one machine — a database with a replica, a cache alongside a database, two microservices that both store user state — you're in CAP territory. And every distributed database you'll ever use has already made this choice for you. DynamoDB chose availability (it always answers, even if the data might be stale). Google Spanner chose consistency (it will delay your read until it's sure you're getting the latest value). MongoDB changed its answer between versions — older versions were more available, newer versions lean toward consistency.

Let's make this concrete. You run an e-commerce platform. Business is great — growing 20% month over month. Your single database in New York handles everything, but you're worried. What if the data center loses power? What if an earthquake hits? And your East Coast response times are great (12 ms), but your West Coast users are seeing 85 ms because every request crosses the entire country.

So you do what every scaling guide tells you: set up a second database in Los Angeles. Both databases serve reads and writes. They replicate data between each other over a fiber-optic cable. For a while, life is beautiful. NYC users hit the NYC database. LA users hit the LA database. Latency drops. You have disaster recovery. Your boss loves you.

Then one Tuesday at 2:47 PM, a construction crew in Nevada accidentally cuts the fiber-optic cable between your two data centers. The databases can no longer talk to each other.

A user in NYC adds an iPhone case to their cart. That write goes to DB-East. But DB-East can't send the update to DB-West — the cable is cut. Now a user in LA (same account — maybe the person's spouse on a shared account) opens the cart. DB-West looks up the cart and returns: empty. Two users, same account, two different realities.

The alternative: when the cable breaks, DB-West stops accepting any reads or writes until it can resync with DB-East. Now LA users see "Service Unavailable." No stale data. No contradictions. But also no service.

This isn't a bug. This isn't bad engineering. This is a fundamental mathematical truth about distributed systems. Eric Brewer proposed it as a conjecture in 2000, and Seth Gilbert and Nancy Lynch formally proved it in 2002. No amount of clever code, no billion-dollar infrastructure, no genius architect can escape it. If your data is on more than one machine, and the network between those machines can fail, you will face this choice.

Now that you've seen the problem, let's define each letter precisely. These definitions matter — CAP is one of the most misunderstood concepts in distributed systems because people use vague definitions and then argue about the wrong things.

Consistency (C): "Every Read Gets the Latest Write"

Think of a shared Google Doc. When your colleague types a sentence, you see it appear in real time. You never see an old version of the document. That's consistency — no matter which server handles your request, you always get the most recent data.

In formal terms: after a write completes successfully, every subsequent read (from any node) returns that written value or a newer one. There are no "stale" reads. Every node in the system agrees on the current state of the data, all the time.

Availability (A): "Every Request Gets a Response"

Think of a 24/7 convenience store. It might not have everything you want. The milk might be from yesterday. But the door is always open. You walk in, you get something. It never has a "closed" sign.

In formal terms: every request to a non-failing node returns a response — no errors, no timeouts. The system is always "open for business." The response might not contain the most up-to-date data, but it will give you an answer.

Notice the subtle but important nuance: availability doesn't promise correct answers — just an answer. A system can be available and return data that's 5 seconds old. That's still available. What it can't do is return a timeoutWhen a system takes too long to respond and the request is abandoned. In HTTP, a 504 Gateway Timeout means the server didn't respond in time. In CAP terms, a timeout means the system is unavailable for that request. or an error saying "try again later."

Partition Tolerance (P): "The System Survives Network Splits"

A network partitionWhen the network between two or more nodes fails, splitting them into groups that can't communicate. It doesn't mean the servers are down — they're running fine — but they can't reach each other. Like two offices where the phone line is cut: both offices are open, but they can't coordinate. is when the network between servers breaks. The servers themselves are fine — they're running, powered on, processing requests. They just can't talk to each other. It's like two offices where the phone line goes dead: both offices are open and staffed, but they can't coordinate.

Partition tolerance means the system keeps operating even when this happens. It doesn't crash, it doesn't shut down — it continues to function in some capacity even though some nodes can't communicate.

Here's the critical insight that changes how you think about CAP: partitions are not optional. In any real distributed system running on physical networks, network failures will happen. Switches fail. Cables get cut. Routers reboot. Cloud providers have network hiccups. Even within a single data center, network partitions occur regularly — Google published a study showing their data center networks experience about one partition event per day across the fleet.

Since partitions will happen no matter what, P isn't really a choice — it's a requirement. A system that can't handle partitions simply isn't distributed. So the real question the CAP theorem asks is:

A lot of people hear "you can't have all three" and think it's just a rule of thumb — like "don't premature-optimize." It's not. It's a mathematical proof. It's as certain as "you can't have a triangle with four sides." Let's walk through it step by step, no math required.

The Setup

Imagine the simplest possible distributed system: two nodes, Node A and Node B, connected by a network. They both store the same piece of data. Right now, both nodes say value = 42.

Step 1: Normal Operation (No Partition)

A client writes value = 99 to Node A. Node A updates its local copy, then sends the update to Node B over the network. Node B receives it and updates its copy too. Now both nodes have value = 99. If a client reads from either node, they get 99. All three properties are satisfied: the data is consistent (both nodes agree), the system is available (both nodes respond), and... well, there's no partition to tolerate. Life is good.

Step 2: A Partition Happens

The network between Node A and Node B breaks. They can't communicate. A client writes value = 99 to Node A. Node A updates its local copy to 99. It tries to send the update to Node B, but the message never arrives — the network is down. Node A has value = 99. Node B still has value = 42.

Step 3: A Read Arrives at Node B

A client sends a read request to Node B. Node B has to respond. And here's where the impossibility kicks in. Node B has exactly two options:

Option 1 — Return 42 (Choose Availability): Node B returns its local value, which is 42. The client gets a response, so the system is available. But the response is wrong — the real value is 99. Consistency is violated. Node B served stale dataData that was correct at some point in the past but has since been superseded by a newer write. It's not "corrupted" data — it's just old. Like a cached web page that hasn't been refreshed..

Option 2 — Refuse to respond (Choose Consistency): Node B says "I can't answer this request because I might have stale data." The client gets an error or timeout. Consistency is maintained (no wrong data was served), but availability is violated — the client didn't get a response.

Why There's No Option 3

Could Node B somehow return 99 — the correct value? No. Node B doesn't know 99 exists. The network is partitioned. The message from Node A never arrived. Node B has no way to know that the value changed. It's not a matter of being clever or having better algorithms — the information physically cannot reach Node B. You can't read a letter that was never delivered.

This is why CAP is a mathematical impossibility, not an engineering challenge. No amount of money, talent, or innovation can make Node B know about a write that it can't receive. The speed of light doesn't help. Quantum computing doesn't help. The information simply isn't there.

By now you know that partitions aren't optional. The network will break at some point — undersea cables get damaged, routers misconfigure, cloud availability zones lose connectivity. Since you can't prevent partitions, the CAP theorem collapses into a single question: when the network breaks, do you want your system to be correct or responsive?

That gives you two real choices — CP and AP. Let's make each one concrete, so you can feel the difference instead of just reading about it.

CP — Consistency + Partition Tolerance

A CP system says: "I would rather give you no answer than a wrong answer." When a node can't verify it has the most recent data — because the network partition means it can't talk to the other nodes — it simply refuses the request. It returns an error, or blocks until the partition heals. The system prefers silence over lies.

Why would you want this? Think about a bank account balanceBanks are the classic CP example. If you have $500 and the system shows $700 due to stale data, you might spend money you don't have. Overdrafts, bounced checks, and fraud all follow from showing the wrong balance.. If the London server doesn't know about a $200 withdrawal that just happened in New York, and it shows "$700" when the real balance is "$500" — the customer might withdraw $600 thinking they have enough. Now you've allowed an overdraft based on stale data. That one wrong answer could cost the bank real money and violate financial regulations.

So the CP approach is: during a partition, the London server detects it can't confirm the latest balance, and it tells the customer "Service temporarily unavailable. Please try again." Frustrating? Yes. But nobody gets the wrong balance, and nobody makes financial decisions based on stale information.

AP — Availability + Partition Tolerance

An AP system says: "I would rather give you a possibly-stale answer than no answer at all." Every node keeps serving requests with whatever data it has locally. If a write happened on the other side of the partition, this node doesn't know about it — but it still responds. After the partition heals, the system reconciles any differences between nodes.

Why would you want this? Think about DNSThe Domain Name System — the internet's phone book. It translates domain names (like google.com) to IP addresses (like 142.250.80.46). DNS is aggressively AP: servers cache records for hours or days, serving potentially stale entries rather than returning nothing. — the system that translates "google.com" into an IP address. If a DNS server can't reach the authoritative server to check for updates, should it refuse to answer? Absolutely not. Telling your browser "I can't resolve google.com" would break the internet. Instead, the DNS server serves whatever cached IP address it has. It might be a few hours old, but it almost certainly still works. A slightly stale answer is infinitely better than no answer.

Same logic for a social media feed. If your Instagram feed shows 2,041 likes on a photo but the real count is 2,043 — does anyone care? Not even a little bit. But if Instagram said "Feed unavailable, try later" every time there was a network hiccup, people would delete the app.

CA — The Ghost Option

You'll see "CA" on many CAP diagrams, usually grayed out. CA means: consistent and available, but doesn't tolerate partitions. In practice, this only exists when there are no partitions — which means a single machine, or machines on a perfectly reliable network (which doesn't exist in production). A standalone PostgreSQL server is technically "CA" because it can't have a partition with itself. But a single server isn't distributed, and if it dies, everything dies. That's why CA is grayed out — it's not a real option for distributed systems.

Theory is nice, but where do the databases you actually use in production land on the CAP spectrum? Let's walk through the major ones — not just labeling them "CP" or "AP," but explaining why they made that choice based on what they were built to do.

CP Systems — Correctness Over Speed

AP Systems — Speed Over Correctness

Here's the dirty secret about CAP: it only tells you what happens during a partitionWhen part of the network can't talk to another part. In practice, full partitions are rare — Google reports about 7.6 per year across their entire infrastructure. Most of the time, your system is operating normally.. But partitions are rare — maybe once or twice a year for most companies, sometimes never. So what trade-off are you making the other 99.9% of the time, when the network is perfectly healthy?

That's the question CAP completely ignores. And it's the question that actually matters for your users' everyday experience.

In 2010, Daniel Abadi — a database researcher at Yale — noticed this gap and proposed PACELCPronounced "pass-elk." Stands for: if Partition, choose Availability or Consistency; Else, choose Latency or Consistency. Published in 2010 by Daniel Abadi. Extends CAP to cover the 99.9% of time when the network is healthy. (pronounced "pass-elk"). The idea is simple but powerful:

The "Else" half is the breakthrough. Even when the network is fine, you face a trade-off every single request: do you replicate data synchronouslySynchronous replication: the write isn't confirmed until ALL replicas have stored it. Slow (must wait for the slowest replica) but consistent — every node always has the latest data. (wait for all replicas before responding — consistent but slow) or asynchronouslyAsynchronous replication: the write is confirmed as soon as the primary stores it. Replicas catch up in the background. Fast (no waiting) but a replica might lag behind by milliseconds to seconds. (respond immediately, let replicas catch up — fast but briefly stale)?

This matters because it affects every single request your system handles — not just the rare moments during a partition. When you're evaluating databases, the "ELC" half of PACELC tells you far more about everyday user experience than the "PAC" half ever will.

The Four PACELC Combinations

PACELC gives you four possible combinations based on what a system chooses during partitions (PA or PC) and what it chooses during normal operation (EL or EC):

PA/EL is the "maximize speed" quadrant. These systems are available during partitions and favor low latency during normal operation. DynamoDB, Cassandra, DNS — they're optimized to respond as fast as possible, all the time. This is the most common AP choice because if you've already decided stale data is acceptable during partitions, you probably also want the speed benefits during normal operation.

PC/EC is the "maximize correctness" quadrant. These systems refuse stale data during partitions and synchronize replicas during normal operation. Spanner, MongoDB (default config), etcd — they never serve data they can't vouch for. The price is higher latency on every request, because every read and write involves coordination across replicas.

PA/EC is an interesting middle ground. The system is available during partitions (accepts stale reads) but uses synchronous replication during normal operation. Azure Cosmos DB with session consistency can behave this way. It's less common because it's a somewhat contradictory stance: "I care about correctness normally, but I'll accept staleness in emergencies."

PC/EL is the rarest combination. Consistent during partitions but favoring low latency normally. Yahoo's PNUTSYahoo's globally distributed database (circa 2008). Used per-record mastership — each record has a "master" region. Reads from the master were consistent, but reads from other regions used local replicas for speed. Discontinued when Yahoo declined. was a notable example. It's hard to build because the mechanisms that provide low-latency reads (read from nearest replica) inherently risk staleness, which conflicts with the consistency guarantee during partitions.

When people say "consistency" in CAP, they usually mean it as a binary: either your data is consistent or it isn't. But in reality, consistency is a spectrum with at least five distinct levels, each offering a different trade-off between correctness and speed. Understanding these levels is crucial because you almost never need the strongest consistency for everything — and using the right level for each operation can make your system both faster and cheaper.

Think of it like shipping options. You can overnight everything — but why pay for overnight shipping on a book you'll read next month? Some data needs to arrive instantly and perfectly. Other data can take the scenic route.

The Five Consistency Levels

Strong consistency (linearizability) — the gold standard. Every read returns the most recent write. Period. It's as if there's only one copy of the data in the entire world. If Alice writes a value and Bob reads it one nanosecond later (from a different continent), Bob sees Alice's write. This is the simplest model to reason about — but the most expensive, because every operation requires coordination across all replicas before responding.

Sequential consistency — slightly weaker. All operations appear in some global order, and that order respects each individual client's sequence. So if you write A then B, everyone sees A before B. But different clients might not see each other's operations in real-time — there could be a brief delay. Think of it like a news broadcast: the events are reported in order, but there's a slight delay from when they happen to when you see them.

Causal consistency — a practical middle ground. If operation A caused operation B (e.g., you post a photo, then someone comments on it), everyone is guaranteed to see A before B. But operations that are unrelated (two people posting photos at the same time, independently) can appear in different orders to different readers. This is often "good enough" because it preserves the logical relationships that matter.

Read-your-writes consistency — a very common guarantee. After you write something, you will always see your own write immediately. But other users might see the old value for a brief window. This is what most social media apps give you: you post a photo and see it immediately in your feed. Your friend across the country might not see it for a few seconds — but you always see your own posts right away.

Eventual consistency — the weakest useful guarantee. If no new writes happen, eventually all replicas will converge to the same value. But there's no guarantee on how long "eventually" takes — could be milliseconds, could be minutes. The only promise is that the system won't stay divergent forever. DNS is a classic example: after you update a DNS record, some servers serve the old IP for minutes or hours, but eventually every server on the internet has the new one.

The Trade-Off Ladder

Each step down the consistency ladder removes a coordination requirement, which directly translates to less waiting:

• Strong consistency requires every replica to agree before responding. If you have replicas in Virginia, Frankfurt, and Tokyo, every write waits for a round trip to Tokyo (~150ms). Every read might need to check with the leader.
• Sequential consistency removes the real-time requirement. Operations are globally ordered, but there's no guarantee that the ordering matches wall-clock time.
• Causal consistency only tracks dependencies between related operations. Unrelated operations skip coordination entirely — huge savings.
• Read-your-writes only coordinates for the originating client. Other clients' views can lag freely.
• Eventual consistency removes all coordination. Respond immediately with whatever data is local. Replicas sync in the background on their own schedule.

The causal consistency example illustrates why you don't always need strong consistency. In a social media app, it would be bizarre to see "Great photo!" before the photo itself appears. Causal consistency prevents that — it tracks that Bob's comment depends on Alice's photo. But it doesn't bother ordering two unrelated posts from different people — one user might see Post X before Post Y, and another user might see the reverse. That's fine. Nobody notices.

Strong consistency would guarantee everyone sees everything in the same order in real-time — but that would require coordinating every single post across every data center, adding hundreds of milliseconds to every write. For a social media feed, that's a terrible trade-off: much slower, for a guarantee nobody needs.

Here's a practical example of mixing consistency levels in one application:

"Eventual consistency" sounds terrifying if you've never seen it in action. It sounds like your data is floating around in chaos, and maybe someday the servers will figure it out. But here's the thing: most of the internet runs on eventual consistency right now, and it works great. When you update your DNS record, it takes minutes to hours to spread across the globe — that's eventual consistency. CDN caches serve stale versions of your website for seconds or minutes after you deploy — eventual consistency. Your social media feed doesn't show a friend's post the exact millisecond they publish it — eventual consistency. And nobody calls any of these systems "broken."

So how does it actually work? The core idea is simple: after some change happens (a write, a partition healing, a replication catch-up), all nodes exchange their differences and merge. Given enough time with no new writes, every replica will hold the exact same data. The interesting — and tricky — part is: what happens when two nodes received conflicting writes during a partition?

Let's break these down one by one.

Last-Writer-Wins (LWW) is the simplest approach: when two nodes disagree, whichever write has the later timestamp wins and the other is silently thrown away. It's dead simple to implement, which is why DynamoDBAmazon's managed NoSQL database. Default conflict resolution is LWW. Designed to always accept writes, even during partitions. and CassandraA distributed NoSQL database originally from Facebook. Every node is equal (no leader). Uses timestamps for conflict resolution by default. both use it as their default. But there's a catch: it silently loses data. If two users edit the same profile at the same time on different nodes, one person's changes simply vanish. For a "likes" counter, that's fine. For user profile updates, it might not be.

Vector clocks take a smarter approach. Instead of a single timestamp, each piece of data carries a "version history" — basically, a list of who changed it and how many times. When two versions arrive with incompatible histories (neither one is "newer" than the other), the system knows there's a genuine conflict. But it can't resolve it automatically — it flags it and hands it to either the application or the user. RiakA distributed key-value store that historically used vector clocks for conflict detection. It would return multiple conflicting versions ("siblings") and let the application merge them. famously used this approach, returning multiple conflicting versions ("siblings") and asking the app to merge them.

CRDTs (Conflict-free Replicated Data Types) are the mathematical solution. These are special data structures — counters, sets, maps — designed so that any order of operations produces the same final result. A G-CounterA "grow-only counter" CRDT. Each node tracks its own increment count separately. The total is the sum of all node counts. Merging is just taking the max of each node's count. Mathematically impossible to conflict. (grow-only counter), for example, tracks each node's count separately. Merging means taking the max of each node's count and summing them. No matter what order you merge, you get the same number. It's mathematically impossible to conflict. The trade-off? CRDTs only work for specific data structures — you can't CRDT-ify arbitrary data.

Application-level resolution is the "you decide" option. The database stores both conflicting versions and your application code contains the merge logic. Amazon's shopping cart is the textbook example: if two versions of a cart conflict, just take the union of all items. You might end up with a slightly larger cart than intended, but that's better than losing items. This is the most flexible strategy, but it means your application needs custom conflict resolution code for every data type that might conflict.

The "Eventually" Problem — How Long Is Eventually?

When people hear "eventually consistent," the natural question is: "OK, but how long is 'eventually'?" The honest answer is: it depends on where the replicas are.

Within the same datacenter, replicas typically converge in 1–5 milliseconds — faster than a human eye blink (which takes about 150ms). Cross-region replication takes 50–200ms, limited by the speed of light through fiber optic cables. During an actual network partition, convergence is delayed until the partition heals — which could be minutes or even hours in the worst case. But that worst case is genuinely rare: most cloud providers measure partition events in minutes per year.

CAP theorem might be the most misunderstood idea in all of computer science. It's only one sentence long, but somehow most engineers — even experienced ones — get it wrong. Blog posts, YouTube videos, and even some textbooks repeat the same myths. Understanding what CAP does not say is just as important as understanding what it does say. Let's kill the six biggest myths.

CAP theorem comes up in almost every system design interview. The bad news: most candidates fumble it by reciting "pick 2 of 3" and stopping there. The good news: you now know more than most candidates. Here's how to turn that knowledge into an answer that impresses.

The 5-Step Framework

Whenever a CAP question lands, follow these five steps in order. This framework works whether the question is "explain CAP" or "classify this system" or "design something globally distributed."

Common Interview Questions

Applying CAP to a Design Scenario

Reading about CAP is the easy part. The hard part is applying it to real decisions — "should this feature be CP or AP?" These exercises start simple and build toward the kind of reasoning that wins system design interviews. Try each one before peeking at the hint.

Pin this to your wall. These ten cards cover every concept on this page in one-liner form — perfect for quick review before an interview or when you're knee-deep in a design doc at 2 AM.

CAP theorem doesn't live in a vacuum — it's the foundation that every other distributed systems topic builds on. Whether you're designing a database, choosing a message broker, or sizing a multi-region deployment, the CP-vs-AP decision shows up everywhere. Pick the topics that matter most for your next interview or project.