Understanding the CAP Theorem: A Cornerstone of Distributed Systems

EH FAHIM — Fri, 04 Jul 2025 19:09:43 +0000

The CAP Theorem is a fundamental concept in the field of distributed computing, describing the trade-offs that system designers face when building distributed data stores. In this article, we’ll explain what the CAP Theorem states, why it’s important, and how it shapes the design of modern distributed systems.

What is the CAP Theorem?

The CAP Theorem formulated by Eric Brewer in 2000 states that in a distributed system, it is impossible to simultaneously guarantee all three of the following properties:

Consistency (C): Every read receives the most recent write or an error.
Availability (A): Every request (read or write) receives a (non-error) response without guarantee that it contains the most recent write.
Partition Tolerance (P): The system continues to operate despite arbitrary partitioning (network failures that split communication between nodes).

The theorem tells us that a distributed system can only provide at most two of these three guarantees at the same time.

Geometric Intuition

Imagine a triangle where each corner represents one of the three properties: Consistency, Availability, and Partition Tolerance. When a network partition occurs which is inevitable in distributed systems you can only choose between Consistency and Availability, because Partition Tolerance becomes a necessity.

This forces system designers to make hard choices depending on the specific requirements of their applications.

Proof Sketch

The theorem is not mathematically proved in the traditional sense but demonstrated through thought experiments and practical examples. When a partition happens:

To maintain Consistency, nodes must agree on the same value before responding which might require rejecting some requests (thus sacrificing Availability).
To maintain Availability, nodes respond immediately even if their data is stale or inconsistent.

Thus, it is impossible to guarantee all three when a partition exists.

Real-World Examples

Here are examples of distributed databases and their design choices:

CP Systems (Consistency & Partition Tolerance): Examples include HBase and MongoDB (in some configurations), where consistency is prioritized over availability during a partition.
AP Systems (Availability & Partition Tolerance): Systems like Cassandra and DynamoDB prioritize availability over strict consistency.
CA Systems (Consistency & Availability): This is only possible if the system assumes no partitions which is unrealistic in distributed systems.

Applications and Impact

The CAP Theorem has guided the design of many modern technologies:

Cloud databases
Distributed file systems
Data replication strategies

It helps engineers decide what trade-offs make sense given their needs whether they prioritize data correctness (Consistency), uninterrupted service (Availability), or resilience to failures (Partition Tolerance).

Final Thoughts

The CAP Theorem reminds us that distributed systems cannot be perfect. Understanding its implications allows developers to make informed decisions about the architecture of their systems. When designing or choosing a distributed database, always ask: which two of the three properties are most important to me?

Versioning technic in short

EH FAHIM — Thu, 21 Apr 2022 12:57:24 +0000

If you ever noticed the version of a software, you must have noticed something like v1.1.0. Today we’ll see how they work. Versioning system like this is called a semantic versioning. In this system there are three numbers, the first one is called the Major version and the second one is called the minor version, and the third one is called the patch version or release. Let’s explain:

The patch version or patch release is for bug fixing, let’s say we have version 4.13.6 of a software and a bug was found, after fixing the bugs the version would be 4.13.7. So, when the developers fix a bug, they will increase the patch version. The Minor version is used for adding new features that will not break the existing software. So, after a minor update the version would be 4.14.0, notice the patch version is reset to 0? It’s because no bugs were found on this version yet, so it could be unstable and as soon as they find a bug, they will increase the patch version. Now if the update contains a breaking change in the software or If it’s a big update they will increase the Major version, so it’ll be 5.0.0.

Extra: In the node package file you will see something like "^4.12.6", this '^' is called the caret character, this means the PM is allowed to install update version of that software as long as the major version is 4. For example, when someone downloads a git repo long after it was uploaded and does npm install, the PM might install newer version like 4.21.6 keeping the major version same. Sometimes the '~' (tilde) character is also used to tell the PM to keep the major and minor version same. So if old version was like 4.12.6 it might install 4.12.16 depending on the software update. So the caret is used to denote 4.x.x and tilde is used to denote 4.12.x.

DEV Community: EH FAHIM