CAP Theorem & PACELC
ReliabilityThe foundational trade-off framework: under a network partition, a distributed system must choose Consistency or Availability — and even without a partition, there's still a Latency/Consistency trade-off (PACELC).
CAP theorem states that a distributed data system can provide at most two of: Consistency (every read sees the latest write), Availability (every request gets a non-error response), and Partition tolerance (the system keeps working despite network partitions between nodes). Since partitions are a fact of life in any real network, the honest framing is: when a partition happens, you must choose C or A — you can't have both. PACELC extends this with the more practically useful half of the story: even when there's no partition (Else), you still trade Latency against Consistency (E), because achieving strong consistency requires coordination round-trips that cost latency.
How it connects
CAP Theorem & PACELC as the source, with the components it typically interacts with.
- → Database Types (SQL, NoSQL & Beyond): CAP is the theoretical lens for every distributed database's design choice — e.g. choosing eventual consistency (AP) vs strict consistency (CP) during a partition.
- → Consensus & Replication Protocols: Consensus protocols (Raft/Paxos) are how CP systems choose consistency over availability during a network partition, by refusing to commit without a quorum.
- → Vector Clocks & CRDTs: AP systems that accept writes during a partition need vector clocks/CRDTs afterward to detect and resolve the resulting conflicting versions.