CAP Theorem

Eric Brewer, states that it is impossible for a distributed computer system to simultaneously provide more than two out of three of the following guarantees:

• Consistency
• Availability
• Partition Tolerance

Consistency means that all members of the system will see the same data at the same time.  A read is guaranteed to return the most recent write or an error in other words commits are atomic across the entire system.  This is not the same thing as C in the ACID.

Availability means that all members of the system will see some data, it could be stale data. It is a guarantee that every request receives a response, no matter the response(success or failure) in a timely manner (no timeouts). They remain accessible and operational all the time.

Partition tolerance means that the system will continue to function even if messages are lost or parts of if do not work correctly or at all.

Now given that networks aren’t completely reliable, partition tolerance must be tolerate. That means that we only have 2 options to choose from when a partition occurs: either consistency or availability. As an example,  NoSQL is about creating choices that focus on availability first and consistency second; RDBMS that adhere to ACID do the opposite. When a partition occurs we must act accordingly. First of all we must be able to detect it. After that we need to enter some kind of “safe-mode” where the actions are limited. The final step is to recover what was lost.

Consistency in CAP means that single copy consistency. This is a subset of the consistency in ACID where a set of database rules must be followed (eg constraints, triggers).

Make no mistake, most of the time the choice must be made only when a partition took place. In rest of the cases no compromise must be made. When designing distributed system, you must follow rules and best practices. Sure, the system will become complex but will compensate with other things.