What is CAP Theorem?

The Core Problem: Imagine you're building a shopping app with servers in California and Virginia. A user in New York updates their cart in Virginia. Milliseconds later, another request from that user hits California. Should California serve the request immediately with potentially stale cart data, or wait to confirm the latest state from Virginia? This is the fundamental question CAP Theorem addresses. What CAP Stands For: CAP Theorem (also called Brewer's Theorem) describes three properties of distributed systems: Consistency (C): Every read receives the most recent write or an error. If you write balance equals 100 at time T, any subsequent read must return 100, never an older value like 80. This is also called strong consistency or linearizability. Availability (A): Every request to a non failed node receives a response within a bounded time, typically matching your Service Level Objective (SLO) like p99 under 100ms. The system cannot return an error just because it's unsure about the latest data. Partition Tolerance (P): The system continues operating despite network failures that split nodes into groups that cannot communicate. A saturated network link, a long garbage collection pause, or a regional outage can all create partitions. The Central Trade-Off: The theorem states: during a network partition, you must choose between Consistency and Availability. You cannot have both simultaneously. Since network partitions are inevitable in real distributed systems (routers fail, cables break, data centers lose connectivity), you're essentially choosing whether your system is CP (maintains consistency during partitions, sacrifices some availability) or AP (maintains availability during partitions, accepts temporary inconsistency).