CAP Theorem: Why You Can't Have All Three

Global hiring doesn't come with a playbook. Join Oyster's webinars and events to learn how leading companies are hiring, expanding, and staying compliant across borders.

Explore Upcoming Events

The difference between growing stores and stagnant ones isn't more effort. It's better insights. StoreClaw analyzes your Shopify and Amazon data, surfaces your biggest growth opportunities, and helps you increase GMV while protecting profit. Start free with bonus tokens. No credit card required.

Try it FREE today

One team cut AI spend by 78% without switching models. They switched gateways. Mesh API: 1000+ models, one endpoint, cheapest routing, per-team token tracking. Estimate Savings.

In 2000, a computer scientist named Eric Brewer stood on stage at the ACM Symposium on Principles of Distributed Computing and made a claim that would reshape how engineers think about databases forever. His conjecture: no distributed system can simultaneously guarantee consistency, availability, and partition tolerance. Two years later, Seth Gilbert and Nancy Lynch at MIT proved him right mathematically. And then everybody misunderstood it.

Every distributed database makes promises about three properties. Here's what each one actually means.

Consistency means every read returns the most recent write. If you write "balance = 500" to Node A, a read from Node B immediately returns 500. Not 400. Not "whatever was cached." The latest value, or an error.

Availability means every request gets a response. No errors, no timeouts, no "service unavailable." The system is always up, always answering. The catch: the answer might be stale.

Partition Tolerance means the system keeps working even when network messages between nodes get lost or delayed. Cables get cut. Routers crash. Packets vanish. A partition tolerant system doesn't fall over when this happens.

Here's where most people get CAP wrong. They hear "pick 2 of 3" and start debating whether they want CP, AP, or CA. But that framing is broken.

In any distributed system, network partitions will happen. It's not a choice. Switches fail. Data centers lose connectivity. Undersea cables get damaged. You can't build a multi node system and say "we've decided to not have network failures." That's like saying "we've decided gravity won't apply to our building."

So the actual choice is CP or AP. That's it. And this choice only matters during a partition, which is rare. During normal operation, you can have all three.

Eric Brewer himself clarified this in 2012, writing that "CAP prohibits only a tiny part of the design space: perfect availability and consistency in the presence of partitions, which are rare."

When a network partition hits a CP system, it refuses to serve data it can't verify. Better to return an error than return wrong data.

etcd runs Kubernetes' cluster state using the Raft consensus protocol. Every write needs agreement from a majority of nodes. If a partition splits your 5 node cluster into a group of 2 and a group of 3, the minority side stops accepting writes entirely. Kubernetes control plane operations fail on that side. But the data stays correct.

MongoDB uses replica sets with a single primary node. During a partition, the side without the primary cannot write. Reads can continue in stale mode, but the default behavior prioritizes consistency.

Google Spanner takes this to the extreme. It uses atomic clocks (a system called TrueTime) to guarantee global consistency across data centers. Google built it because their AdWords billing system could not tolerate two nodes disagreeing about an account balance. When money is on the line, correctness wins.

AP systems make the opposite call. During a partition, they keep serving requests on both sides. The data might be stale. Conflicts get resolved later.

Amazon built DynamoDB because their shopping cart had to work 100% of the time. A customer adding items to their cart should never see an error page, even during a network split. If two nodes accept conflicting writes during a partition, DynamoDB reconciles them after the partition heals using vector clocks.

Cassandra does the same thing. Both sides of a partition keep accepting reads and writes. When connectivity restores, it uses last write wins to merge conflicting data.

Netflix chose this path deliberately. They run on Cassandra plus EVCache. A user seeing slightly outdated recommendations is fine. A user seeing an error page is not. For a streaming service, availability is the product.

You'll occasionally see articles claiming certa

in systems are "CA" (consistent and available, no partition tolerance). This is misleading.

A single PostgreSQL instance is technically CA. It's consistent and available. But it's not distributed. The moment you add replication across a network, you must handle partitions. There's no opt out.

CA is a valid category only for single node databases. And single node databases aren't what CAP theorem is about. If your "distributed system" runs on one machine, you don't have a distributed system. You have a database.

CAP has a major gap. It only describes what happens during a partition. But partitions are rare events. What about the 99.9% of the time when the network is healthy?

Daniel Abadi proposed the PACELC framework in 2010 to fix this. It asks two questions instead of one:

That second question is what CAP completely misses. Even with no partition, replicating data across nodes forces a trade off. Do you wait for all replicas to confirm a write (consistent, but slower)? Or do you acknowledge immediately and replicate in the background (fast, but briefly inconsistent)?

Notice the pattern. Systems that prioritize availability during partitions also tend to prioritize latency during normal operation. And systems that prioritize consistency during partitions also pay the latency cost even when things are fine.

Here's what most CAP explanations miss entirely. The old framing treats CP vs AP as a permanent, system level decision. Modern databases threw that out.

Cassandra lets you set a consistency level on every single query. Ask for ONE and you get speed (read from the nearest node, don't wait for confirmation). Ask for QUORUM and you get correctness (wait for a majority of nodes to agree). Same database, different guarantees, different queries.

DynamoDB offers eventually consistent reads by default (fast, possibly stale) and strongly consistent reads on request (slower, guaranteed fresh). You pick per read.

Azure Cosmos DB goes furthest with 5 consistency levels: strong, bounded staleness, session, consistent prefix, and eventual. You dial the knob per operation.

The trade off decision has moved from the database vendor to the engineer writing the query. That's a massive shift. Your payment service can demand strong consistency while your recommendation feed uses eventual consistency. Same database cluster, different guarantees for different operations.

→ Find me on : Social Links

That’s it for today, keep learning!
Scortier, Signing Off!