CAP theorem, also known as Brewer’s theorem, was developed by computer scientist Eric Brewer and is a theorem in the field of distributed systems.

This theorem is essential if you want to design a distributed architecture system.

**C is Consistency. **C is Consistency. A is Availability. P is for Partition tolerance. In distributed systems, you can’t have all three, you can only have two. That’s the CAP theorem. ** For example, you cannot guarantee availability if you guarantee consistency and fault tolerance of partitions.

Consistency

In this case, the consistency is strong consistency. Strong consistency means that if node A updates data, node B can update data at the same time, so that each time the client reads data, the data is updated. However, the theorem ignores the network latency in our daily life. In reality, network delay is still unavoidable, so we can only achieve the final consistency, but the goal is still close to strong consistency, that is, try to reduce the delay time.

Availability

Availability refers to the need for non-failing nodes to return a reasonable response at a reasonable time. A reasonable response means no error, no timeout failure. For example, node A updates the data and wants to release it to node B at the same time, but the intermediate transmission cable is cut by the excavator. At this time, the user accesses node B, and node B should return the old data instead of reporting errors. That’s usability. Let the user feel that the system still works.

Partition tolerance

Partition fault tolerance refers to the normal operation and response of the system when the network is partitioned. For example, node A and node B can’t communicate, and you have to think about how the system should. Although the probability of network partitioning is low and short, it can happen. So in theory you have to sacrifice C or A, and P has to be achieved.

For example, drop the P. At this time, the system needs to ensure CA, and then network partition occurs. Node A and node B cannot communicate with each other. At this time, the client wants to write data to node A, but the data cannot be synchronized to node B. So the only way to guarantee consistency is to make sure that A doesn’t write. So if you don’t let the client write data to A, you just send an error back to the client saying you can’t write at this time, is that A usability violation?

So P must be guaranteed in a distributed system. So in a distributed system it’s CP and AP.

The CA? Please note that there can only be two of the three caps mentioned in CAP, so CA can be matched. CA matches when there is no P in the system. In other words, C and A should be satisfied when the system does not have partitions, and C or A should be discarded depending on the situation after the system has partitions.

Pay attention to

CAP theory is not system level, it is data level. What does that mean?

This means that in the case of network partitioning, you can have some data following CP and some data following AP. For example, in user registration scenarios, users can log in to CP to ensure successful login after registration. And the user changes the avatar this kind of AP, after all, with the old data will not have a great impact.

Therefore, we need to choose different solutions according to different business scenarios. Caps can be used flexibly