Understanding the CAP Theorem and How PACELC Extends It

CAP Theorem

In distributed systems, various failures such as server crashes, disk loss, or network partitions can occur, prompting the need for a model that balances consistency, availability, and partition tolerance. The CAP theorem states that a system cannot simultaneously provide all three properties.

Consistency (C) : All nodes see the same data at the same time, effectively providing a single up‑to‑date copy.

Availability (A) : Every non‑failed node must respond to each request, ensuring the system remains accessible even when some nodes fail.

Partition Tolerance (P) : The system continues to operate despite communication breaks between nodes.

Because a network partition is inevitable, a system must choose between consistency and availability when a partition occurs.

What the CAP Theorem Misses

Traditional relational databases (ACID) prioritize consistency, while many NoSQL databases (BASE) prioritize availability, illustrating the trade‑off implied by CAP. The theorem does not address system behavior when no partition exists.

PACELC Theorem

The PACELC theorem extends CAP by adding a consideration for latency versus consistency when the system is operating without partitions. It states:

If a partition exists (P), the system trades off between Availability (A) and Consistency (C).

Else (E), when no partition exists, the system trades off between Latency (L) and Consistency (C).

This adds the “ELC” component to the original CAP framework.

Examples

Dynamo and Cassandra : PA/EL systems that choose availability during partitions and lower latency otherwise.

BigTable and HBase : PC/EC systems that always favor consistency, sacrificing availability and latency.

MongoDB : Typically a PA/EC system in its default primary‑secondary configuration, opting for availability during partitions while maintaining consistency in the primary path; it can be configured as PC/EC when writes require majority acknowledgment.

Conclusion

The CAP and PACELC theorems help architects balance consistency, availability, partition tolerance, and latency in distributed systems, guiding design decisions for various databases and replication strategies.