System Design - CAP Theorem

CAP in system design stands for:

C - Consistency

A - Availability

P - Partition tolerance

To build a strong distributed architecture we need the data to always be consistent, system should always be available and it should also support partitions tolerance.

Having all these capabilities is like a dream come true.

But sadly in reality we can only achieve two capabilities and we have to trade off one out of three. Lets try to understand this with different combinations:

Consistency and Partition tolerance:

In the banking domain, we need to keep the user’s account balance data and transaction history consistent on all platforms. If a user withdraw amount from ATM, the updated amount should be reflected immediately.

Hence, we need data consistency in banking sectors and they also need to support partition tolerance just in case if one node goes down the backup node can work so, we need to trade off availability.

Availability and Partition tolerance:

While using social media platforms, we try to be keep our website or applications highly available. We can compromise on consistency, as we can reflect a post or a comment after some seconds but we do not want to hamper the user experience.

Hence, to provide amazing user experience we have to highly available and support partition tolerance but we can compromise on consistency.

Consistency and Availability:

If only one data base is present and it is being used for all the CRUD operations, no doubt it is going to be consistent and we have a monolith application that is using the database, it is going to support availability but its not going to be fault tolerant.

Hence, to be consistent and highly available we have to trade fault/partition tolerance.

When dealing with distributed architecture our system should support fault/partition tolerance in every scenario, so the choice will come to consistency or availability.