Skip to content
Author: ytianle

CAP theorem⚓︎

Distributed Systems (a collection of interconneected nodes that share data) is not perfectly reliable.

OOP != Networking Programming⚓︎

When we do OOP, we take granted that objects can communicate with each other seamlessly within the same memory space. However, in Distributed Systems, nodes may be located on different machines, and network issues can lead to communication failures.

This is where the CAP theorem becomes relevant, as it highlights the trade-offs that must be made when designing distributed systems.

CAP⚓︎

The CAP theorem is a principle that describes the limitations of Distributed System. It states that in a distributed system, you can only guarantee 2 out of the following 3 properties simultaneously:

  1. Consistency (C): Every read receives the latest write or an error, ensuring that all nodes in the system return the same data.

  2. Availability (A): Every request (read or write) receives a response, even if some nodes in the system are down.

  3. Partition Tolerance (P): The system continues to operate even if there is a communication breakdown between some parts of the system (network partitions).

alt text

Applications of CAP⚓︎

Trade-offs in Distributed Systems⚓︎

Since networks aren't completely reliable, you must tolerate partitions in a distributed system (0-partition tolerance), thus you have to choose between:

  • Maintain Consistency: Ensure that all nodes see the same data at the same time, but some requests may fail (returns an error/timed-out error). We choose CP when the business requirements dictate atomic reads and writes. alt text
  • Maintain Availability: Ensure that every request receives a response, but some nodes may return stale or inconsistent data. We choose AP when the business requirements can tolerate synchronization delays. alt text

Real-world Examples⚓︎

In essence, the CAP theorem helps designing distributed systems based on the trade-offs between these properties. In practice, many well-known systems exhibit dominant design tendencies under partition scenarios:

  • C over A (CP tendency): Redis, HBase, MongoDB

  • A over C (AP tendency): DynamoDB, Cassandra, Couchbase

  • C + A under no partition assumption (CA*): Traditional RDBMS such as MySQL, PostgreSQL, SQL Server

picture 1

More resources for learning!

The CAP theorem does NOT classify systems into rigid categories. Instead, it highlights the tendencies of systems to prioritize certain properties over others during network partitions. Many distributed systems can be configured to favor different properties based on specific use cases and requirements.

Reference⚓︎