CAP theorem | Part-2

Alisha Chhabra
Last Updated: May 13, 2022

Introduction 

Before proceeding with the discussion, we would like to draw your attention to Part-1, where the basics are covered with real-time examples. 

What's new in this article? Well, the previous article covers the three attributes of CAP, i.e., Consistency, Availability, and Partition tolerance, in detail; In this section, we'll be walking you over the advanced features of the CAP theorem and the misconceptions regarding the CAP theorem.

Let us get started now:

What is the CAP theorem?

According to the CAP theorem, a distributed system cannot be consistent, available, and partition tolerant simultaneously. In layman's terms, the CAP theorem allows you to decide how to handle your distributed database systems when a few database servers refuse to connect owing to a system fault.

Let us go over these attributes one more time:

Consistency in distributed systems

Consistency means the user should see the same data regardless of whatever node they connect to on the system. This is the most recent data that has been written to the system. That also means, If a write operation occurs on a node, it should be replicated to all of its replicas. As a result, every time a person connects to the system, they will see the same information.

Availability in distributed systems

The term "availability" refers to the fact that every request from the user should elicit a response from the system. Whether the user wishes to read or write, they should receive a response even if the action fails.

Partition tolerance in distributed systems

A communication break between nodes in a distributed system is referred to as a partition. In other words, if a node in the system cannot receive messages from another node in the system, there is a partition between the two nodes. Partitioning could have occurred due to a network failure, a server crash, or for any other reason.

Now, if the partition means the breakdown of the communication between the nodes, partition tolerance means the system should work even if there is a partition in the system. 

A distributed database system is bound to have partitions in a real-world system due to network failure or some other reason. As a result, partition tolerance is a property that we cannot avoid while designing our system. As a result, a distributed system will choose to sacrifice consistency or availability but not partition tolerance.

This made us think about picking up either consistency or availability with partition tolerance. 

The CAP theorem, also known as Brewer’s theorem, entails a distributed database system choosing between consistency and availability when a partition occurs.

CP or AP

Is it possible to have high consistency and high availability at the same time in distributed databases?

CA databases are typically monolithic databases that operate on a single node and offer no distribution. As a result, they do not require partition tolerance. In contrast to distributed databases which operate on multiple nodes hence need partition tolerance. 

Understanding CAP theorem with examples

Let us now understand the CAP theorem with some examples:

Understanding CP with MongoDB

With the help of MongoDB, let's try to understand how a distributed system would behave if it decided to forego Availability during a partition:

MongoDB is a NoSQL database that stores data in JSON files in one or more Primary nodes.

Each primary node has numerous replica sets that update themselves asynchronously, utilizing the primary node's operation log file. The system's replica set nodes send a heartbeat (ping) to every node to track whether other replicas or primary nodes are alive or dead.

If no heartbeat is received within 10 seconds, the node is considered unavailable.

If a primary node becomes unavailable, one of the secondary nodes must take over as the primary node. Until a new primary is chosen from among the secondary nodes, the system is unavailable to the user for further write queries.

As a result, the MongoDB system operates as a Consistent system while sacrificing Availability during a partition.

Now let us look at one example that prefers Availability over Consistency:

Understanding AP with Cassandra 

Cassandra is often known as a highly available database since it compromises availability. Let us understand how?

Cassandra is a peer-to-peer computing system. It is made up of several nodes in the system. In addition, each node can accept a user's read or write request. Cassandra keeps many data replicates in distinct nodes. This results in a masterless node architecture with several points of failure rather than a single point.

The replication factor regulates the number of data replicas. If the replication factor is 3, the data will be replicated on three nodes in a clockwise direction.

From this, one can quickly get an idea of how Cassandra architecture works to provide high availability. Still, it seems a smooth process that also does not let the consistency suffer. But that’s not true. 

Let us understand why?

A partition may occur, and the replica will not receive an updated copy of the data. The replica nodes will still be available to the user in this case, but the data will be inconsistent. Cassandra, on the other hand, provides eventual consistency. That is, all updates will eventually reach all replicas. However, it allows conflicting versions of the same data to exist momentarily until we get them back to constant.

‘2’ of ‘3’ is misleading

Consistency, Availability, and Partition Tolerance are not binary attributes. All of them are, in fact, continuous variables in large-scale distributed systems spanning data centers.

First, you can't indeed choose between Consistency and Availability. If you forego Partition tolerance, you effectively lose Consistency and Availability because you can't preserve them both in the event of a network partition. Network partitions are something over which you don't have much control; they are simply defects that will occur at some point. As a result, you must pick between CP and AP.

But even that isn't entirely correct. Unless your network is unstable, you can usually have both Consistency and Availability. You don't have to select between these if your network isn't partitioned.

Even in-network partition, you don't always have to choose the same guarantee: it may be advantageous in some circumstances to maintain Consistency. In others, it may be preferable to have Availability.

Let us now have a look at some faqs based on the discussion we had:

Frequently asked questions 

Q1. What is the difference between vertical and horizontal scaling? 

Ans. Vertical scaling (also known as scaling up) refers to adding new resources to a system to fulfill demand. While horizontal scaling refers to adding new nodes, vertical scaling refers to increasing the power of your existing machines. If your server demands more processing power, for example, vertical scaling would imply updating the CPUs. You can also scale the RAM, storage, or network speed vertically.

Q2. Provide any real-time web application that focuses on availability and relaxes consistency. 

Ans. Google Search prioritises availability above consistency; the results you see will be determined by the server's state that responds to your request, and different servers may have inconsistent states.

 

Q3. What does the modern CAP theorem entail?

Ans. The goal of modern CAP should be to maximise the combinations of consistency and availability that are appropriate for the individual application. A method like this includes strategies for operating during a partition as well as recovery after that.

 

Q4. Give an example of a web application that employs eventual consistency.
Ans. Gmail and Facebook, for example, often impose just eventual consistency. Messages may take some time to travel across servers, causing various servers to have conflicting views of the world based on what messages they have seen thus far. However, all servers will eventually have consistent states because the correct state is defined by reading messages in their global timestamps rather than the order in which they came.

Key takeaways 

To sum up the session, we’ve looked at the various distributed database systems that utilize the concept of CAP theorem. Now that you have a great understanding of what exactly CAP theorem entails and some misconceptions about it. 

Most importantly, all three attributes are not binary but in contiguous portions, which let the system forfeit the attribute based on the condition.

I hope this article provides you with a better understanding of the CAP theorem, the hot topic of system design. To upgrade yourself, follow up on the more good articles and enhance your knowledge. 

Thanks for investing your time here. 

Have fun reading!

Was this article helpful ?
0 upvotes

Comments

No comments yet

Be the first to share what you think