The CAP Theorem
The problem
When a network partition splits a distributed database into two halves that can't talk to each other, each half has to choose: keep answering requests (possibly with stale or conflicting data) or stop answering until the partition heals — you can't have perfectly consistent, always-available data across an unreliable network at the same time.
Why now
Distributed system basics established that partial failure — specifically, network partitions — is unavoidable; the CAP theorem is the precise, provable statement of what a system must sacrifice once a partition actually happens, turning a vague intuition ('there's a tradeoff somewhere') into a specific choice with a name.
Mental model
CAP says you can have at most two of Consistency (every read sees the latest write), Availability (every request gets a response), and Partition tolerance (the system keeps working despite network splits) — but partitions are a fact of networking, not optional, so in practice the real choice is between consistency and availability during a partition, not whether to tolerate partitions at all.
Requires
- Distributed System BasicsDistributed Systems
CAP is a precise statement about exactly the partial-failure scenario (a network partition) that distributed-system-basics establishes as unavoidable; you need that scenario as a real possibility before CAP's tradeoff is meaningful rather than abstract.
- Replication & BackupsDatabase Engineering
CAP's consistency question only arises because data is replicated across multiple nodes that can disagree; you need the concept of multiple copies of the same data before 'do they agree' is a question worth asking.
Unlocks
Used in
- Choosing between databases (PostgreSQL vs. Cassandra vs. DynamoDB) based on their CAP tradeoffs
- Explaining why a distributed database might return stale data under certain failure conditions, by design
- System design interviews, where CAP is a recurring, foundational framing tool
- Justifying an architecture's consistency model to stakeholders who assume 'the data is always correct'
Projects
- Given three real databases' documented behavior during a partition, classify each as CP or AP and justify the classification from their own documentation
- Design a small feature (e.g. a 'like' counter) twice — once prioritizing strict consistency, once prioritizing availability — and explain what each version sacrifices during a partition
Examples
- A banking system typically chooses consistency over availability during a partition — better to reject a transaction than risk an incorrect balance
- A social media 'like' count typically chooses availability over consistency — showing a slightly stale count is fine, refusing to load the page is not
Resources
- CAP Theorem — Julia Evansarticle
Mastery checklist
- I can state the CAP theorem precisely and explain why partition tolerance isn't really optional
- I can classify a real database as prioritizing consistency or availability during a partition
- I can design a feature's data behavior deliberately around a CP or AP choice
- I can explain CAP to a non-technical stakeholder using a concrete example