CAP Theorem in System Design

According to the CAP theorem, only two of the three desirable characteristics consistency, availability, and partition tolerance can be shared or present in a networked shared-data system or distributed system.

• The theorem provides a way of thinking about the trade-offs involved in designing and building distributed systems.
• It helps to explain why certain types of systems may be more appropriate for certain use cases.
• The theorem states that a distributed system can have at most two of these guarantees.

Properties of CAP Theorem

The property of three distributed system characteristics to which CAP Theorem refers:

1. Consistency

Consistency defines that all clients see the same data simultaneously, no matter which node they connect to in a distributed system. For eventual consistency, the guarantees are a bit loose. Eventual consistency gurantee means client will eventually see the same data on all the nodes at some point of time in the future.

Below is the explaination of the above Diagram:

• All nodes in the system see the same data at the same time. This is because the nodes are constantly communicating with each other and sharing updates. 
• Any changes made to the data on one node are immediately propagated to all other nodes, ensuring that everyone has the same up-to-date information.

2. Availability

Availability defines that all non-failing nodes in a distributed system return a response for all read and write requests in a bounded amount of time, even if one or more other nodes are down.

Below is the Explanation of the above Diagram:

• User send requests, even though we don't see specific network components. This implies that the system is available and functioning.
• Every request receives a response, whether successful or not. This is a crucial aspect of availability, as it guarantees that users always get feedback.

3. Partition Tolerance

Partition Tolerance defines that the system continues to operate despite arbitrary message loss or failure in parts of the system. Distributed systems guranteeing partition tolerance can gracefully recover from partitions once the partition heals.

Below is the Explanation of the above Diagram:

• Addresses network failures, a common cause of partitions. It suggests that the system is designed to function even when parts of the network become unreachable.
• The system can adapt to arbitrary partitioning, meaning it can handle unpredictable network failures without complete failure.

Trade-Offs in the CAP Theorem

We can classify the systems into the following three categories:

1. CA System

A CA System delivers consistency and availibility across all the nodes. It can't do this if there is a partition between any two nodes in the system and therefore does't support partition tolerance.

2. CP System

A CP System delivers consistency and partition tolerance at the expense of availability. When a partition occurs between two nodes, the systems shuts down the non-available node until the partition is resolved. Some of the examples of the databases are MongoDB, Redis, and HBase.

3. AP System

An AP System availibility and partition tolerance at the expense of consistency. When a partition occurs, all nodes remains available, but those at the wrong end of a partition might return an older version of data than others. Example: CouchDB, Cassandra and Dyanmo DB, etc.

Example to Understand the CAP Theorem

In the figure above,

• We have a simple distributed system where S1 and S2 are two server. The two server can talk to each other. Here, System is partition tolerant. Here We will prove that system can be either consistent or available.
• Suppose there is a network failure and S1 and S2 cannot talk to each other. Now assume that the client makes a write to S1. The client then send a read to S2.
• Given S1 and S2 cannot talk, they have different view of the data. If the system has to remain consistent, it must deny the request and thus give up on availability.
• If the system is available, then the system has to give up on consistency. This proves the CAP Theorem.

Use Cases of the CAP Theorem in System Design

Here we will see how we can use all the trade-off system in real application:

1. Banking Transactions (CP System)

Problem Statement:

Imagine a bank teller updating your account balance on a secure computer system. This system prioritizes consistency (C) and partition tolerance (P).

Why we use CP System ?

• Each transaction must be accurately reflected across all servers (consistency) even if individual branches face network disruption (partition tolerance).
• Inconsistency could lead to double spending or incorrect balances, unacceptable situations in financial transactions.
• While data is always consistent, some users might experience momentary delays during network issues due to stricter synchronisation requirements.

2. Social Media Newsfeed (AP System)

Problem Statement:

Think of your newsfeed on a social media platform constantly updating with new posts and stories. This system prioritizes availability (A) and partition tolerance (P).

Why we use AP System ?

• Users expect immediate access to their newsfeeds (availability) even if parts of the network are temporarily down (partition tolerance). Slight inconsistencies in data, like seeing a friend's post slightly sooner on one device than another, are tolerable in this context.
• Data might not be perfectly consistent across all servers immediately after updates. Users might occasionally see slightly different versions of their newsfeed before data propagates across the system.

3. Online Shopping Cart (Hybrid System CAP System):

Problem Statement:

Imagine an online shopping cart, adding items, and checking out. This system might employ a hybrid approach balancing CAP trade-offs.

Why we use AP and CP System?

• Adding items to the cart could be available and partition-tolerant (AP), allowing uninterrupted browsing even if temporary network glitches occur.
• But when confirming the order and processing payment, the system might switch to a CP mode, ensuring consistency across all servers before finalising the transaction.
• The system requires careful design to switch seamlessly between availability and consistency modes at the right points to handle different stages of the user journey effectively.