CAP Twelve Years Later: How the Rules Have Changed
Eric Brewer2012IEEE Computer 2012
Read it on doi.org(opens in a new tab)Why this one
CAP is usually taught as a triangle where you pick two corners, which is memorable and mostly wrong in the ways that hurt real designs. Brewer is correcting his own slogan: partitions are not a steady state, consistency is not one knob, and availability is not a boolean if your users, replicas, and operations differ. Read this after Dynamo and Spanner: Dynamo shows the availability first side in production, Spanner shows how far you can push consistency with clocks and careful engineering, and this paper gives you the vocabulary to stop arguing in bumper stickers. The useful move is to treat a partition as a failure mode with scoped choices, not as a permanent architecture label. If you are designing an API, queue, cache, or database, this is worth an evening because it turns CAP from interview trivia into an incident playbook.
What to take away
- Partitions force choices per operation, not once for the whole system.
- Availability depends on whose request succeeds, where, and under which failure.
- Modern systems mix strong and weak consistency instead of wearing one CAP label.
Reads with
- Dynamo: Amazon's Highly Available Key-value Store
shows availability first design as scoped conflict handling under partitions
- Spanner: Google's Globally-Distributed Database
shows how far consistency can go when clocks become part of the protocol
- Time, Clocks, and the Ordering of Events in a Distributed System
gives the ordering model behind the clocks Spanner uses to escape simple CAP slogans