# An Easier Way to Consider the CAP Theorem

> CAP is usually taught as "pick two of three." A more useful framing is a single question — when the network partitions, does your system keep consistency or availability?

- Author: Chet Mancini
- Published: 2015-03-19
- Canonical: https://chetmancini.com/writing/an-easier-way-to-consider-the-cap-theorem/
- Originally published: https://blog.chetmancini.com/an-easier-way-to-consider-the-cap-theorem

When talking about distributed systems, it is common to describe Eric Brewer's [CAP Theorem](https://en.wikipedia.org/wiki/CAP_theorem) as "Consistency, Availability, and Partition Tolerance. Pick Two." This is [usually illustrated with a triangle or Venn Diagram](https://www.google.com/search?tbm=isch&q=cap+theorem). While that's not terribly wrong, it's not particularly helpful.

Given that network partitions are rare, but do happen, the better way to consider the theorem is: "In the event of a network partition, does your system guarantee consistency or availability?"

Lets say you have a system with incoming data.

![Incoming data arrows splitting toward two databases separated by a horizontal line representing a network partition](https://chetmancini.com/writing/an-easier-way-to-consider-the-cap-theorem/cap-partition.png)

*Figure: Incoming data meets a partitioned system.*

If your system splits, do you stop accepting data (choosing consistency, sacrificing availability), or do you accept the requests and attempt to "fix" the integrity of the data at a later point (choosing availability and living with "eventual consistency")? Even from this simplified diagram, it is clear that is absolutely impossible to have a full system with all three properties at the same instant, which is why the CAP theorem is provably true.

I have found this illustration somewhat more helpful and somewhat more correct than triangles. The theorem is certainly quite nuanced, and I plan to write on other aspects of the theorem and distributed systems in the future.

I definitely want to give a hat tip to [Nathan Marz](http://nathanmarz.com) for a similar explanation which I repurposed here.