Skip to content
#Software

CAP Theorem

#Software #Architecture #DistributedSystems #SystemDesign

The famous CAP theorem has come true 25 I wanted to know what it was, why it came and how it came about. About it. fine by Eric Brewer, author of the theorem, who wrote more 10 Years ago, I wanted to remember it because it was good.) Let’s start with the statement of the theorem. (citation)

The CAP theorem states that any networked shared-data system can have at most two of three desirable properties:

  • consistency (C) equivalent to having a single up-to-date copy of the data;
  • high availability (A) of that data (for updates); and
  • tolerance to network partitions (P). We need to remember about her appearance.
  • 25 years ago, autumn 1998 The CAP theorem was formulated.
  • 1999 It was published in the article "Harvest, Yield, and Scalable Tolerant Systems"in ACM
  • 2000 Symposium on Principles of Distributed Computing (presentation here)
  • 2002 formally proven (where the consistency of the theorem has become linearizability) Then the theorem went to the masses and became a conditional "select." 2 properties of three: C, A, P, which is a strong simplification for three reasons, as Eric points out in the above article:
  1. Due to the rarity of the partition, there is no point in choosing between C and A. (More on this next time we discuss PACELC Theorem)
  2. The decision on C or A is made not once for all components and all data, but at a different level of granularity and may depend on the type of operation or data.
  3. C, A, P are not binary properties, but rather continuous properties. 0 before 100%, levels of consistency are also different and even parts have nuances:)

In the end, Eric says that in the absence of system separation, we can choose A or C, and in times of problems we should have a clear algorithm. Determining what partition has happened Transition to an explicit partition mode, in which some operations can be limited start the process of restoring consistency and compensating for errors that may have been partitioned

Then Eric talks about the acronyms ACID, BASE and CAP.

  • BASE Basic Availability, Soft State and Ultimate Consistency. The first two properties help achieve accessibility when the system is divided into parts.
  • ACID It stands for Atomicity, Consistency, Isolation, Durability. This acronym is known to many who have worked with relational databases, but as I wrote above Consistency from CAP and ACID is about different and it adds to the difficulty in understanding:)

The next part is about latency, which is absent in the classical formulation, but implicitly present. After all, performing an operation in a divided system, we at some point have to make a decision.

  • cancel the operation and reduce availability Continue the operation, but accept the risk of data inconsistency

Of course, you can try to do the operation again. (retries)But it just puts off making a decision for a while. From a pragmatic point of view, separation is a time limit. (time-out)which we put into our communication. And there are several consequences.

  1. There is no global concept of partition because some nodes can detect partition and others cannot.
  2. Those nodes that found partition enter partition-mode, the part where we have to choose between C and A. As a result, the system designers set time bounds to meet the target speeds of the system's response to requests, and the tougher these time bounds, the higher the probability of falling into partition mode, even just with a slow network, but without real separation.

In the above article, there are many more interesting ideas about scope consistency and how it relates to data centers, how to clearly manage the transition to partition mode and recover from partition. I highly recommend reading it.

#Software #Architecture #DistributedSystems #SystemDesign