The 2012 Gmail Outage
In 2012, a network partition split Google's data centers. Gmail chose consistency - it refused to serve data that might be stale. Users got errors instead of emails. Meanwhile, YouTube chose availability - it kept serving videos even if view counts were slightly stale. Same company, same partition event, different trade-offs because the data had different requirements.
The Three Properties
The CAP Triangle:
Consistency (C)
/ \\
/ You can \\
/ only pick \\
/ TWO during \\
/ a partition \\
/ \\
Availability (A) ---------- Partition Tolerance (P)
C - Consistency: Every read gets the most recent write.
All nodes see the same data at the same time.
A - Availability: Every request gets a response (success or failure).
The system never refuses to answer.
P - Partition Tolerance: System works despite network splits
(messages lost or delayed between nodes).Why P Is Non-Negotiable
Network partitions WILL happen. Cables get cut, switches fail, cloud regions have outages. You cannot choose to not have partitions. So the real choice is: when a partition happens, do you sacrifice Consistency or Availability?
During a network partition:
Node A Node B
[latest data] X X X X [stale data]
(network
broken)
Client reads from Node B. Two choices:
CP (Consistency): Node B says 'ERROR - I cannot confirm
I have the latest data. Try again later.'
--> User gets an error, but never sees wrong data.
AP (Availability): Node B says 'Here is what I have'
--> User gets a response, but it might be stale.
Data will sync when partition heals.CP Systems: Consistency Over Availability
During a partition, CP systems refuse to serve requests that might return stale data. They prefer returning an error over serving wrong information.
CP Systems - When wrong data is DANGEROUS:
System Why CP Partition Behavior
----------- -------------------------- ---------------------
ZooKeeper Coordination/elections Minority nodes stop
etcd K8s cluster state Raft consensus
MongoDB Financial data, inventory Primary unavailable
HBase Consistent analytics Region server down
Redis Cluster Cache consistency Reject writes
Use case: Bank balance, inventory count at checkout,
distributed locks, leader election.
'I would rather show an error than a wrong balance.'AP Systems: Availability Over Consistency
During a partition, AP systems keep serving requests, accepting that responses might be stale. Data converges when the partition heals.
AP Systems - When downtime is WORSE than stale data:
System Why AP Partition Behavior
----------- --------------------------- ---------------------
Cassandra Always-on, multi-DC Serves from local DC
DynamoDB Shopping cart, sessions Eventually consistent
CouchDB Offline-first sync Merge on reconnect
DNS Name resolution everywhere Stale records OK
CDN caches Content delivery Serve cached version
Use case: Social media feed, product catalog, DNS,
shopping cart, user preferences.
'I would rather show a slightly stale feed than an error.'The Misconception Everyone Gets Wrong
CAP does NOT mean you always give up C or A. During normal operation (no partition), you can have BOTH consistency and availability. The choice only applies DURING a partition. And most of the time, your system is not partitioned. It is like a fire escape plan - you hope you never need it, but you must decide in advance.
Interview Tip
When an interviewer asks about CAP, say: 'Partitions are inevitable in distributed systems, so the real choice is CP or AP during a partition. For financial data like account balances, I would choose CP - better to show an error than a wrong balance. For a social media feed or product catalog, I would choose AP - a slightly stale feed is better than downtime. In practice, most real systems use different consistency levels for different data - strong consistency for payments, eventual consistency for recommendations.'
Key Takeaway
CAP theorem says: during a network partition, choose consistency (reject requests) or availability (serve potentially stale data). Since partitions are unavoidable, design each component of your system based on which sacrifice is acceptable for that specific data and use case.