cap-theorem-tradeoffs
CAP-Theorem Tradeoffs
Concept of the skill
CAP is Brewer's 2000 conjecture, formalized by Gilbert and Lynch in 2002: during a network partition, a distributed data system cannot guarantee both replica consistency and availability. Partition tolerance is not a selectable feature in real networks; the practical design question is what the system must do when messages are delayed or lost.
Use this skill to name the partition-mode choice and then extend it with PACELC for the more common steady-state latency-vs-consistency tradeoff. It is a distributed-data-systems frame, distinct from ACID's single-transaction guarantees, isolation-level tuning, replication topology design, or sharding mechanics.
Coverage
The consistency-availability-partition-tolerance trade-off that physics imposes on distributed data systems. Covers Brewer's 2000 conjecture, Gilbert & Lynch's 2002 formal proof, why P is mandatory in real networks (the practical choice is CP vs AP, not "any two of three"), the PACELC extension (Abadi 2010) that names the latency-vs-consistency trade-off in the non-partition case, the CAP-C vs ACID-C confusion that is the most-common misconception in the space, the spectrum of consistency models from linearizability to eventual consistency, the four PACELC quadrants (PA/EL, PA/EC, PC/EL, PC/EC) and the systems that occupy each, and the partition-mode choice procedure.
Philosophy of the skill
CAP is the frame that made distributed-systems design honest. Before Brewer's 2000 conjecture and Gilbert & Lynch's 2002 proof, the industry made contradictory claims about consistency, availability, and fault tolerance; after CAP, those claims have shape. Under partition — which physics guarantees will happen — you preserve consistency at the cost of availability, or availability at the cost of consistency.
The discipline is making the choice per workload and intentionally. A banking core ledger is right to be CP. A shopping cart's session state is right to be AP. A multi-region content-delivery system is right to be AP with eventual consistency. A schema registry is right to be CP. The choice is the engineering team's responsibility; CAP names the trade-off; the design realizes the choice.
PACELC is the frame that made CAP practical. Most systems spend the overwhelming majority of their time not partitioned; PACELC's E (else) case names the latency-vs-consistency trade-off in the common case, which is where most users' actual experience lives. A team that designs for CAP without PACELC has optimized for the rare event and ignored the daily one.