You Can't Have All Three — The Constraint That Defines Distributed Systems

In 2000, computer scientist Eric Brewer proposed what became known as the CAP theorem: in a distributed data system, you can have at most two of three desirable properties — Consistency, Availability, and Partition Tolerance. You cannot have all three simultaneously.

This was formalized as a proof in 2002. Since then it has shaped how every large-scale internet system is designed. Not as a nice-to-have — as a hard constraint.

The three properties

Consistency (C): Every read receives the most recent write or an error. If you write a value and then immediately read it from any node in the system, you get that value. The system behaves as if it were a single node, even if it's running on thousands of machines.

Availability (A): Every request receives a response — not an error, a real response, even if the data might not be the most recent version. The system keeps responding even if some nodes are degraded.

Partition Tolerance (P): The system continues operating even if network communication between some nodes is lost or delayed. A partition is a network split — some nodes can no longer talk to others. A partition-tolerant system survives this and keeps working.

Why you can't have all three

Imagine two database nodes, Node A and Node B, storing the same data. A user writes a new value to Node A. Before Node A can replicate this to Node B, the network link between them fails — a partition occurs.

Now another user reads from Node B. What happens?

• If you prioritize Consistency: Node B must either return the new value (which it doesn't have yet) or an error. It returns an error. You've sacrificed Availability.
• If you prioritize Availability: Node B returns whatever it has — the old value. You've sacrificed Consistency.

There is no third option. The partition is real; you must choose which property to give up.

Why partition tolerance isn't optional in practice

In a real distributed system — anything running on multiple machines connected by a network — partitions happen. Networks fail, cables are cut, routers crash, data centers lose connectivity. You cannot build a distributed system that is immune to partitions; you can only choose how to respond when they occur.

This means the practical choice is almost always between CP (Consistency + Partition Tolerance) or AP (Availability + Partition Tolerance). CA — Consistency + Availability — requires a system that never experiences a partition, which means a single node, not a distributed system.

Real systems and their choices

CP systems prioritize consistency over availability. Traditional relational databases (PostgreSQL, MySQL in strict configurations) and systems like HBase and Zookeeper lean this way. During a partition, they'd rather reject a request than serve stale data. Banks and financial systems often want this: it's better to tell a customer "service temporarily unavailable" than to show them an incorrect account balance.

AP systems prioritize availability over strict consistency. DynamoDB (in eventual consistency mode), Cassandra, and CouchDB lean this way. They'll serve slightly stale data rather than reject requests. A social media feed that shows a post from 30 seconds ago instead of 5 seconds ago is tolerable — a feed that's unavailable is not.

The refinement: PACELC

The CAP theorem describes behavior during partitions, but a partition is an abnormal state. Daniel Abadi proposed PACELC as an extension: even when there's no partition, you still face a tradeoff between Latency and Consistency. A system can write to all replicas synchronously (high consistency, higher latency) or write to one and propagate asynchronously (lower latency, eventual consistency). This is the tradeoff that dominates normal operation.

Systems like DynamoDB let you configure where on the spectrum you want to sit. Read-your-own-writes consistency is a common middle ground: you'll always see your own most recent write, but other users might see a slightly older state.

The broader lesson

CAP theorem is a specific technical result, but its deeper lesson applies everywhere: in complex systems with multiple independent actors, you cannot optimize every desirable property simultaneously. Adding redundancy improves availability but introduces consistency challenges. Optimizing for speed sacrifices some safety. Decentralizing for resilience creates coordination costs.

The discipline of distributed systems design is fundamentally about making explicit, reasoned tradeoffs rather than hoping to avoid them. Most failures in software architecture — and in organizational design — come from assuming you can have all three.

2000 में computer scientist Eric Brewer ने CAP theorem प्रस्तावित किया: किसी भी distributed data system में एक साथ तीन में से अधिकतम दो properties हो सकती हैं — Consistency, Availability, और Partition Tolerance। तीनों एक साथ संभव नहीं।

2002 में इसे formally prove किया गया। तब से हर बड़े internet system का design इसी से shaped है।

तीन properties क्या हैं

Consistency (C): हर read सबसे recent write देता है या error। किसी भी node से read करो — वही data मिलेगा जो अभी-अभी लिखा गया।

Availability (A): हर request का जवाब मिलता है — भले ही data थोड़ा पुराना हो। System error नहीं देता, कुछ न कुछ response देता है।

Partition Tolerance (P): अगर nodes के बीच network टूट जाए, तो भी system काम करता रहता है।

तीनों एक साथ क्यों नहीं

मान लीजिए दो nodes — A और B — एक ही data store करते हैं। User Node A पर नई value लिखता है। उससे पहले कि A, B को update करे — network fail हो जाता है। अब दूसरा user B से read करे:

• अगर Consistency priority है: B error देगा — पुरानी value नहीं देगा। Availability गई।
• अगर Availability priority है: B पुरानी value देगा। Consistency गई।

तीसरा option नहीं है।

Partition tolerance optional नहीं है

Real distributed systems में partitions होते हैं — network fail होती है, routers crash करते हैं। आप इसे रोक नहीं सकते। इसलिए practical choice CP (Consistency + Partition Tolerance) या AP (Availability + Partition Tolerance) के बीच है। CA (बिना Partition Tolerance के) का मतलब single node — distributed system नहीं।

असली systems के choices

CP systems: PostgreSQL, HBase, Zookeeper — partition के दौरान request reject करेंगे, पर stale data नहीं देंगे। Banks के लिए यही सही है: "service unavailable" बताना गलत balance दिखाने से बेहतर है।

AP systems: DynamoDB (eventual consistency mode), Cassandra, CouchDB — थोड़ा पुराना data देंगे, पर available रहेंगे। Social media feed में 30 second पुरानी post tolerable है — unavailable feed नहीं।

बड़ी सीख

CAP theorem technical result है, पर इसकी deeper सीख सब जगह लागू होती है: complex systems में, जहां कई independent actors हों, सभी desirable properties एक साथ optimize नहीं हो सकतीं। Redundancy बढ़ाओ — consistency की चुनौती आती है। Speed optimize करो — कुछ safety जाती है।

अधिकतर software architecture failures — और organizational design failures — इस assumption से आती हैं कि "हमें तीनों मिल जाएंगी।"