# Problem with CAP

Fonte: http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html Autor: Daniel Abadi (Professor of Computer Science at Yale University)

- Como professor de DBMS e estudioso do CAP acha que há uma falha no Teorema de CAP.
- Baseado na definição de CAP, há 3 tipos de sistemas distribuídos:
  - CA: consistent and available, but not tolerant of partitions
  - CP: consistent and tolerant of network partitions, but not available
  - AP: available and tolerant of network partitions, but not consistent
- Problema 1: pesos da influência de C e A em sistemas CP e AP
  - Sistemas AP sacrificam a consistência o tempo todo, funcionam assim.
  - Sistemas CP sacrificam a disponibilidade somente quando ocorre um problema.
  - A e C são assimétricos, ou seja, não tem o mesmo percentual de influência sobre o sistema.
- Problema 2:
  - Não há diferença prática entre sistemas CP e CA.
  - CP systems give up availability only when there is a network partition.
  - CA systems are “not tolerant of network partitions”.
  - But what if there is a network partition? What does “not tolerant” mean?
  - In practice, it means that they lose availability if there is a partition.
  - Hence CP and CA are essentially identical.
  - So in reality, there are only two types of systems: CP/CA and AP.
  - If there is a partition, does the system give up availability or consistency?
  - Having three letters in CAP and saying you can pick any two does nothing but confuse this point.
- Problema 3:
  - CAP focuses everyone on a consistency/availability tradeoff
  - Resulting in a perception that the reason why NoSQL systems give up consistency is to get availability.
  - But this is far from the case. A good example of this is Yahoo’s NoSQL system PNUTS or Sherpa.
  - PNUTS, rather than giving up just one of consistency or availability, the system gives up both!
  - It relaxes consistency by only guaranteeing “timeline consistency” where replicas may not be consistent with each other but updates are guaranteed to be applied in the same order at all replicas.
  - However, they also give up availability --- if the master replica for a particular data item is unreachable, that item becomes unavailable for updates.
  - Why would anyone want to give up both consistency and availability? CAP says you only have to give up just one!
  - The reason is that CAP is missing a very important letter: L.
  - PNUTS gives up consistency not for the goal of improving availability. Instead, it is to lower latency.
  - Keeping replicas consistent over a wide area network requires at least one message to be sent over the WAN in the critical path to perform the write
  - Unfortunately, a message over a WAN significantly increases the latency of a transaction (on the order of hundreds of milliseconds), a cost too large for many Web applications that businesses like Amazon and Yahoo need to implement.
  - Consequently, in order to reduce latency, replication must be performed asynchronously.
  - This reduces consistency (by definition). In Yahoo’s case, their method of reducing consistency (timeline consistency) enables an application developer to rely on some guarantees when reasoning about how this consistency is reduced.
  - But consistency is nonetheless reduced.
- Conclusion: Replace CAP with PACELC
  - To me, CAP should really be PACELC --- if there is a partition (P) how does the system tradeoff between availability and consistency (A and C); else (E) when the system is running as normal in the absence of partitions, how does the system tradeoff between latency (L) and consistency (C)?
  - Systems that tend to give up consistency for availability when there is a partition also tend to give up consistency for latency when there is no partition. This is the source of the asymmetry of the C and A in CAP. However, this confusion is not present in PACELC.
  - For example, Amazon’s Dynamo (and related systems like Cassandra and SimpleDB) are PA/EL in PACELC --- upon a partition, they give up consistency for availability; and under normal operation they give up consistency for lower latency. Giving up C in both parts of PACELC makes the design simpler --- once the application is configured to be able to handle inconsistencies, it makes sense to give up consistency for both availability and lower latency.
  - Fully ACID systems are PC/EC in PACELC. They refuse to give up consistency, and will pay the availability and latency costs to achieve it.
  - In conclusion, rewriting CAP as PACELC removes some confusing asymmetry in CAP, and, in my opinion, comes closer to explaining the design of NoSQL systems.