The CAP theorem: Consistency and Availability except when Partitioned
By CrisPedregal on Jul 19, 2013
Some NoSQL databases present their implementations of eventual consistency (or other weak consistency variants) as an inevitable consequence of Brewer's CAP Theorem. The reasoning justifying such design choices goes more or less like this:
This reasoning, however, is flawed, because it relies on a simplistic interpretation (* above) of the CAP theorem. This phrasing is simplistic because the three properties of the CAP theorem are not fully orthogonal, nor is each a binary quantity, and each may have different values at different levels of a system. For example, the question of whether a system is currently partitioned, may not admit a single system-wide consistent answer. A better phrasing of CAP is:
In a distributed system, you can have both Consistency and Availability, except when there is a Partition.
Relaxing the consistency requirements usually makes it easier to maintain availability, but the CAP theorem is not an excuse to give up strong consistency across the board. A well-designed system can balance both availability and consistency while tolerating partitions over a range of tradeoffs, where eventual consistency is just one possibility. The next post discusses these points in more detail.