CAP Theorem (NIS)

The CAP theorem, also known as Brewer’s theorem, is a concept in distributed systems that states that it is impossible for a distributed system to simultaneously provide all three of the following guarantees: Consistency, Availability and Partition Tolerance.

C – Consistency

All nodes in the distributed system see the same data at the same time. In other words, every read receives the most recent write. Imagine you have a shared to-do list app, and you and your friend both add tasks. With consistency, whenever you check the list, you see the latest tasks your friend added, and vice versa.

A – Availability

Every request to the distributed system receives a response, without guarantee that it contains the most recent version of the information. In our to-do list example, if the app is available, you can always add, remove, or view tasks. Even if your friend is temporarily offline, you can still use the app independently.

P – Partition Tolerance

Partition tolerance deals with the system’s ability to continue working even when some parts of the network are not functioning correctly. Going back to the to-do list, imagine you and your friend are using the app on different devices, and suddenly there’s a problem with the internet connection. Partition tolerance allows the app to keep functioning on both devices, even if they can’t communicate right away.

The CAP Theorem

The CAP theorem states that in a distributed system, you can’t have all three of Consistency, Availability, and Partition Tolerance at the same time. You need to make trade-offs based on your priorities.

Examples of CAP Trade-Offs:

Consistency and Availability (CA): Imagine a bank system where consistency is crucial. If you deposit money, you want to be sure that your balance is immediately updated. In this case, the system might become temporarily unavailable if there are network issues to maintain strong consistency.

Consistency and Partition Tolerance (CP): Consider a cloud-based document editor where multiple users collaborate. If there’s a network partition, the system may prioritize consistency, and collaboration features may be temporarily disabled until the network is restored.

Availability and Partition Tolerance (AP): Think of a social media feed where new posts are added frequently. If there’s a network issue, the system might prioritize availability, allowing you to see and post updates, but there’s a chance you might not immediately see the latest posts from others due to eventual consistency.

Example: Amazon DynamoDB (AP System)

DynamoDB is a highly available and partition-tolerant NoSQL database service provided by Amazon Web Services (AWS). It prioritizes availability and partition tolerance over strong consistency. In the event of network partitions, DynamoDB allows nodes to continue operating independently, providing high availability, but it might lead to eventual consistency as nodes reconcile their state.

Example: Google Spanner (CA System)

Google Spanner is a globally distributed, strongly consistent database. It prioritizes both consistency and availability over partition tolerance. Spanner uses synchronized clocks across its data centers to achieve a globally consistent timestamp ordering of transactions. While this design provides strong consistency, it may lead to reduced availability in the face of network partitions.

Understanding the CAP theorem helps architects and developers make informed decisions about the design and trade-offs in distributed systems based on the specific requirements of their applications. Different scenarios may call for different choices along the consistency-availability-partition tolerance spectrum.

Check this video on CAP Theorem


Published by Active Learning, Dec 2023