When data is spread and replicated across several nodes, a fundamental question arises: can we simultaneously guarantee that all reads see the most recent data, that the system always responds, and that it tolerates network failures? The CAP Theorem proves that we cannot: we must choose. Understanding this trade-off is essential for designing the data storage of any distributed system, and for choosing correctly among the dozens of databases available today.

In this lesson we will study the CAP Theorem, its PACELC refinement, the difference between strong and eventual consistency, and classify the most common databases according to the guarantees they offer.

1. The three properties: C, A, and P
2. The statement of the CAP Theorem
3. Why P is not optional in practice
4. CP versus AP: the real choice
5. PACELC: beyond CAP
6. Strong versus eventual consistency
7. Table of databases by CAP
8. Common mistakes and tips
9. Exercises
10. Conclusion

The CAP Theorem, formulated by Eric Brewer, deals with three properties of a distributed data system:

Beware: the "Consistency" of CAP is not the "C" of ACID. Here it means that all replicas agree, not transactional integrity.

The theorem states:

In the presence of a network partition, a distributed system can only guarantee two of the three properties: either consistency or availability, but not both.

Imagine two replicated nodes that stop communicating (partition). A write arrives at one of them. Now a read arrives at the other node, which does not have that write. The system must decide:

• Return the old data (maintains availability, sacrifices consistency).
• Reject the read or wait (maintains consistency, sacrifices availability).

There is no third option. That is why CAP is a choice, not a buffet.

Many people believe they can choose "CA" (consistency and availability, giving up P). In a truly distributed system this is an illusion: network partitions happen (cables get cut, switches fail, extreme latencies). You cannot guarantee that there will never be a partition.

Therefore, in a distributed system P is mandatory, and the real choice comes down to:

• CP: during a partition, I prioritize consistency (I may stop responding).
• AP: during a partition, I prioritize availability (I may return old data).

A "CA" system only makes sense on a single machine (a classic relational database on a single server), where there is no network to partition.

The decision depends on the business case:

The guiding question is always: what is worse for my business, giving an incorrect response or giving no response?

CAP only talks about what happens during a partition, which is a rare event. PACELC, formulated by Daniel Abadi, completes the picture by adding what happens the rest of the time:

Partition: Availability or Consistency; Else (in normal operation): Latency or Consistency.

In other words:

• If there is a Partition → you choose between A and C (as in CAP).
• If there is not (Else) → you still choose between Latency and Consistency, because guaranteeing strong consistency between replicas requires coordination, which costs time.

PACELC is more useful than CAP in day-to-day work, because most of the time there are no partitions, and yet you still pay a price for consistency.

Eventual consistency does not mean "incorrect data forever", but rather that, if writes stop arriving, all replicas eventually agree. There are useful intermediate levels, such as read-your-own-writes (a user always sees their own changes).

What is interesting about systems like Cassandra is that you tune consistency per operation: critical writes with QUORUM, tolerant reads with ONE. If reads and writes together add up to more replicas than the total (W + R > N), you obtain strong consistency on top of an AP base system.

An indicative classification (many are configurable and can move between categories):

Take this table as a guide, not as dogma: the specific configuration (replication factors, consistency levels) determines the actual behavior.

• Confusing the C in CAP with the C in ACID: in CAP it is "all replicas agree"; in ACID it is "transactional integrity". They are not the same.
• Believing you can choose CA in a distributed system: partitions happen; you must choose between CP and AP.
• Applying strong consistency to everything: it increases latency and reduces availability needlessly. Reserve strong consistency for critical data.
• Ignoring PACELC: the cost of consistency is also paid when there are NO partitions, in the form of latency.
• Choosing a database because it's trendy: choose according to the guarantees your business case needs, not the most talked-about technology.

1. State the CAP Theorem and explain why, in a real distributed system, the practical choice comes down to CP or AP.
2. For each case, indicate whether you would choose strong consistency (CP) or eventual (AP) and justify: (a) the balance of a bank account, (b) the number of "likes" on a post, (c) booking a seat at a cinema.
3. Explain what PACELC adds compared to CAP and what the "PA/EL" classification means.

1. CAP says that, during a network partition, a distributed system can only guarantee two of the three properties (C, A, P). Since partitions are inevitable in a truly distributed system, P is mandatory; therefore, the real choice is between CP (sacrificing availability to maintain consistency) and AP (sacrificing consistency to maintain availability).

2. (a) CP/strong: an incorrect balance is unacceptable; better an error than wrong data. (b) AP/eventual: a momentary lag in "likes" is irrelevant; always responding takes priority. (c) CP/strong: we cannot sell the same seat twice, so consistency rules.

3. PACELC adds what happens when there is no partition: even then you must choose between Latency and Consistency. "PA/EL" means: during a Partition prioritize availability (A), and in normal operation (Else) prioritize low Latency (at the cost of consistency). It is the profile of systems like Cassandra.

We have learned that the CAP Theorem imposes an inevitable trade-off: during a network partition, you must choose between consistency (CP) and availability (AP). PACELC refines the idea by reminding us that, even without partitions, we pay in latency for consistency. The choice between strong and eventual consistency, and the database that underpins it, must always respond to the needs of the business: is an incorrect response or no response worse?

With this lesson we close Module 4, Distributed Architectures and Microservices. You have traveled the complete path: from the fundamentals of distributed systems and their fallacies, through decomposition into microservices and bounded contexts, communication mechanisms, resilience patterns, all the way to data consistency trade-offs. This knowledge enables you to design robust distributed systems, aware of their limits and suited to each business problem.