The CAP Theorem
The CAP theorem, formalized by Eric Brewer in 2000 and proven by Seth Gilbert and Nancy Lynch in 2002, states that a distributed data system can provide at most two of the following three guarantees simultaneously: Consistency (every read receives the most recent write or an error), Availability (every request receives a non-error response, without guaranteeing it contains the most recent write), and Partition Tolerance (the system continues to operate despite arbitrary message loss or delay between nodes). Because real networks fail — cables get cut, switches misbehave, data centers lose connectivity — partition tolerance is not optional in a distributed system; it is a fact of life you must design around. The practical consequence is that CAP is really a choice between C and A only during an actual network partition, not a permanent architectural label you slap on a system.
Cricket analogy: The CAP theorem is like a cricket board realizing that during a stadium's Wi-Fi outage, the scoreboard app must choose between showing only fully verified scores (consistency) or showing something to fans even if slightly outdated (availability) — since network failures during a match are a fact of life, not optional.
Why Partition Tolerance Isn't Optional
A single-node database can trivially be both consistent and available because there is no network between replicas to partition. The moment you replicate data across two or more nodes to survive failures or reduce latency, you have created a distributed system, and distributed systems experience partitions — this is an empirical fact about networks, not a design choice. So the real question CAP forces you to answer is not 'do I want P?' but 'when a partition happens, do I sacrifice C or A?' Systems that pick CP (like a majority-quorum configuration of etcd or ZooKeeper) will refuse to serve reads or writes on the minority side of a partition rather than return stale or conflicting data. Systems that pick AP (like Cassandra or DynamoDB in their default configurations) will keep answering requests on both sides of the partition, accepting that some responses may be stale or that conflicting writes will need to be reconciled later.
Cricket analogy: A single scorer with one scorebook is trivially both accurate and always available; the moment you add a backup scorer in another room (replication) to survive outages, you risk them disagreeing during a connectivity drop — a CP-style board (like a strict review system) halts scoring on the disconnected side, while an AP-style board keeps announcing scores on both sides and reconciles later.
CP vs. AP in Practice
Choosing CP means every acknowledged write is durable and every read reflects the latest acknowledged write, but during a partition some nodes must stop responding to preserve that guarantee — this is the right tradeoff for systems like leader-election services, distributed locks, or financial ledgers where a stale or wrong answer is worse than no answer. Choosing AP means the system remains responsive to every request even during a partition, accepting eventual consistency and the need for conflict resolution (last-write-wins, vector clocks, or CRDTs) — appropriate for systems like shopping carts, social media feeds, or presence indicators where availability and low latency matter more than perfect freshness. Most production systems are not purely CP or AP everywhere; they make the CP/AP choice per subsystem or even per operation, since a single application often has both strongly consistent needs (billing) and eventually-consistent-tolerant needs (view counts).
Cricket analogy: Choosing CP is right for the official run tally where a wrong answer is worse than no answer, like a DRS review that must halt play rather than guess; choosing AP is right for a stadium's "fans watching" counter where staying responsive matters more than perfect accuracy — a single broadcast often needs both.
Normal operation (no partition):
[Client] --write--> [Node A] --replicate--> [Node B]
\-------> [Node C]
All nodes agree; reads from any node return the latest value.
During a network partition:
[Client] --write--> [Node A] X [Node B] [Node C]
partition
CP choice: Node A refuses the write (or the minority side refuses
reads/writes) unless it can reach a quorum -> system becomes
UNAVAILABLE on the minority side, but stays CONSISTENT.
AP choice: Node A accepts the write locally and serves reads
immediately -> system stays AVAILABLE on both sides, but Node A
and Nodes B/C now DISAGREE until the partition heals and values
are reconciled.Amazon's DynamoDB paper (2007) is the canonical real-world AP example: it deliberately chose availability over strict consistency for shopping-cart writes, because losing a customer's 'add to cart' click is worse for the business than briefly showing an out-of-date cart that gets merged later. Google's Spanner, by contrast, leans CP, using synchronized atomic clocks (TrueTime) to minimize the window of uncertainty so it can offer strong consistency globally while still achieving very high — though not unlimited — availability.
Beyond CAP: PACELC
Daniel Abadi's PACELC extension notes that CAP only describes behavior during a Partition (P), where you choose Availability or Consistency (A or C); but Else (E), when the system is running normally, you still face a tradeoff between Latency (L) and Consistency (C). A system can be described more completely as PA/EL (favor availability during partitions, favor latency normally — e.g. Cassandra) or PC/EC (favor consistency during partitions and normally — e.g. many traditional relational replication setups). This framing is more actionable for engineers because network partitions are rare events, while the latency-consistency tradeoff is something every synchronous replication decision makes on every single request.
Cricket analogy: PACELC is like recognizing that rain delays (partitions) force a choice between an accurate DLS recalculation or a quick estimate, but even on a clear day (Else) a scorer must choose between waiting for the official confirmation (consistency) or posting the score instantly (latency) — a fast-paced T20 broadcast favors instant posting (PA/EL), while an official Test match record favors waiting for confirmation (PC/EC).
- CAP theorem: during a network partition, a distributed system must choose Consistency or Availability — it cannot fully guarantee both.
- Partition tolerance is not optional for any system with more than one node; real networks partition.
- CP systems (etcd, ZooKeeper, Spanner) reject requests on the minority side during a partition to preserve strong consistency.
- AP systems (Cassandra, DynamoDB) keep serving requests during a partition and reconcile conflicts afterward via mechanisms like last-write-wins or vector clocks.
- The choice is often made per-subsystem, not globally, since different data has different consistency requirements.
- PACELC extends CAP by also describing the latency-vs-consistency tradeoff that exists even when there is no partition.
Practice what you learned
1. According to the CAP theorem, when a network partition occurs, a distributed system must choose between which two guarantees?
2. Why is partition tolerance generally treated as non-negotiable in distributed systems design?
3. Which system design choice best describes Cassandra's default behavior during a network partition?
4. What does the 'EL' in a PACELC classification of 'PA/EL' mean?
5. A distributed lock service like etcd, used for leader election, is typically designed as CP rather than AP. Why?
Was this page helpful?
You May Also Like
Consistency Models
Consistency models define the contract about what values reads may return after concurrent writes, ranging from strict linearizability to loosely-ordered eventual consistency.
Consensus Algorithms
Consensus algorithms let a group of distributed nodes agree on a single value or ordered log despite failures and network delays, underpinning leader election and replicated state machines.
Database Replication
Explains how copying data across multiple database nodes improves read throughput and fault tolerance, and the consistency tradeoffs of leader-follower and multi-leader setups.
Distributed Transactions
Distributed transactions coordinate atomic, all-or-nothing updates across multiple independent services or databases, using protocols like two-phase commit or pattern-based sagas.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics