CAP Theorem
CAP says a distributed system can guarantee only two of three properties at the same time:
- C: Consistency. Every read returns the most recent write, so all nodes show the same data.
- A: Availability. Every request gets a (non-error) response, even if some nodes are down.
- P: Partition Tolerance. The system keeps working even when network communication between nodes breaks.
The key point: P isn’t really optional
In a distributed system, networks will fail eventually (cables cut, data centers lose connectivity, packets drop). So partition tolerance is a given, and the real choice is:
When a network partition happens, do you choose Consistency (CP) or Availability (AP)?
When there is no partition, you can have both C and A. The trade-off only bites during failures.
Real-world example (the intuition)
Imagine a bank with two branches, Jaipur and Mumbai, each holding a copy of your balance (₹10,000). The phone line between them goes down (a partition), and you withdraw ₹8,000 in Jaipur.
- CP choice: Mumbai refuses to serve you until it can sync with Jaipur. Data stays correct, but the service is unavailable.
- AP choice: Mumbai keeps serving you, so you could withdraw another ₹8,000 there. The service stays up, but the data is inconsistent (overdraft).
AP systems (Availability > Consistency)
Slightly stale data is acceptable, and downtime is not.
System -> Why AP works
Instagram / Facebook : If a like count or follower count is off by a few for a moment, nobody is harmed. A feed that won’t load is a real problem.
LinkedIn : A profile update or new connection can take a few seconds to appear everywhere.
Amazon shopping cart (Dynamo) : Amazon would rather always accept “add to cart” and merge conflicts later than lose a sale.DNSCached records may be stale for a while, but the internet keeps resolving.
Netflix (viewing history, recommendations) : Stale “Continue Watching” is fine. Streaming must not stop.
Typical tech: Cassandra, DynamoDB, CouchDB, Riak. These use eventual consistency: all nodes converge to the same data after a short time.
CP systems (Consistency > Availability)
Wrong data is worse than no data, so it’s better to reject or delay a request than to return something incorrect.
System -> Why CP is needed
Get Riyajangid’s stories in your inbox
Join Medium for free to get updates from this writer.
Banking / UPI transactions : Double-spending or wrong balances are unacceptable. A “try again later” is fine.
Stock trading platforms : Two people must never buy the same share at conflicting prices. Ticket/seat booking (e.g., BookMyShow, IRCTC)One seat can’t be sold twice.
Inventory for limited stock (flash sales) : Overselling leads to cancellations and angry customers.
Coordination services (ZooKeeper, etcd) : Leader election and configuration need a single source of truth.
Typical tech: HBase, Google Spanner, ZooKeeper, etcd, Redis (in cluster/strong modes), MongoDB (default configuration), traditional RDBMS with synchronous replication.
What to use when
Question to ask:
Is incorrect or stale data dangerous (money, safety, legal, inventory)?
If yes → CP , If no → Consider AP
Is downtime very costly (user-facing, high-traffic, global)?
If yes → AP , If no → Consider CP
Can users tolerate seeing slightly old data for a few seconds?
If yes → AP , If no → CP
Do you need strict ordering or transactions (ACID)?
If yes → CP, If no → AP
Do you need to scale massively across regions with low latency?
If yes → AP, If no → (usually)Either
Quick rule of thumb:
- Money, bookings, identity, stock counts → CP
- Social, content, analytics, feeds, logs, caches → AP
Hybrid approach (very common in real systems)
Most large companies don’t choose one for the whole system. They choose per feature:
- Amazon: the shopping cart is AP, but payment and order placement are CP.
- Uber: the map and nearby-driver view are AP, but the payment and trip billing are CP.
- Instagram: feed and likes are AP, but login credentials and account changes are stricter.
Conclusion
CAP theorem doesn’t tell you which database is “best”. It tells you what you are giving up when things go wrong. Since network partitions are unavoidable in distributed systems, the real decision is between Consistency and Availability:
- Choose AP when user experience and uptime matter more than perfectly fresh data (social media, streaming, e-commerce browsing).
- Choose CP when correctness is non-negotiable (banking, trading, booking, inventory).
- In practice, mix both, applying the right trade-off to each part of your system.
A good system designer doesn’t ask “Which is better?” but rather “What is the cost of being wrong vs. the cost of being down for this feature?”
