The CAP Theorem or Brewers theorem states that it is impossible in a distributed system, while ensuring the three properties consistency, availability and partition tolerance.
According to the CAP theorem, a distributed system two of the following properties meet, but not all three.
Because only two of the three requirements can be fully met simultaneously in distributed systems, the CAP theorem is often visualized as a triangle with a particular application can be classified in one of the edges.
System properties C, A and P can in this case be seen as a gradual quantities, ie availability is high when the system responds quickly, and low when the system responds slowly. In terms of consistency, this means that this is either secured immediately (with strict consistency) or only after a certain time window of inconsistency ( "BASE " principle ( = Basically Available, Soft state, Eventual consistency ) many NoSQL databases ).
The theorem was established in 2000 as a guess of the computer scientist Eric Brewer at the University of California, Berkeley at the " Symposium on Principles of Distributed Computing" ( PODC ). In 2002, Seth Gilbert and Nancy Lynch of MIT published an axiomatic proof of Brewer's conjecture and thus established this as a theorem.
AP - Domain Name System (DNS) and cloud computing
The DNS falls in the AP class. Availability is extremely high, as tolerance to the failure of individual DNS servers. However, the consistency is not always immediately: it can sometimes take days to a modified DNS entry is propagated to the entire DNS hierarchy, and is thus seen by all clients.
Cloud platforms rely on a horizontal scale, that is, the load is distributed among many nodes, which consist of cheaper does not necessarily fail-safe hardware ( can ). Therefore, a cloud application must be able to show individual nodes mandatory tolerance to the failure. High availability is also required. It follows that a cloud application (at least in large part ) also falls in the AP class. Examples of web applications that are not dependent on strict consistency, would be social media sites like Twitter or Facebook; when individual messages do not arrive simultaneously for all users, thus the principal function of the service is not compromised.
Since a strict consistency because of the CAP theorem can not be guaranteed here, a totally inconsistent data management is also not desired, one must come to terms with weaker consistency conditions. As a counterpart to the ACID principle of relational databases put many NoSQL databases on the BASE principle: Basically Available, Soft state, Eventual consistency. Eventual consistency can be mutatis mutandis translate well with " finite consistency statements ," that is: the system after a certain ( short as possible ) period of inconsistency in a consistent state.
CA - Relational Database Management System (RDBMS )
The classical relational databases such as DB2 or Oracle strive especially for consistency.
An RDBMS cluster will fall into the category CA. You strive especially for availability and consistency of all nodes. Since they are mostly operated with highly available networks and servers, they do not necessarily have a way with a partitioning. As already mentioned, C, A and P provide gradual sizes.
CP - banking applications
For distributed financial applications such as ATM is the consistency of the data paramount: An aloof amount of money must be reliably charged on the accounts page, deposited funds must appear on the account. This requirement must also be ensured for data transmission errors ( partition tolerance).
Compared with the consistency and partition tolerance is the availability of secondary importance (CP ): for network disturbances to an ATM machine or any other service not be available rather than not conduct proper transactions. An alternative could also be to reduce the partitioning at a maximum lift-off amount of money in order to reduce the potential damage. However, this solution is then professionally and has itself no longer as much to do with the CAP Theorem.