# #18: The PACELC Theorem

*Hello! Today, we will extend the CAP theorem introduced yesterday with a new theorem: PACELC.*

PACELC is an extension of the CAP theorem, introduced by Daniel Abadi. It’s an acronym that stands for:

**P**: Partition**A**: Availability**C**: Consistency**E**: Else*← New***L**: Latency*← New***C**: Consistency

While the core concepts remain similar to those in the CAP theorem, PACELC extends the idea by introducing a second decision point. Let’s explore what the theorem is about and why it matters.

The PACELC theorem expands the CAP theorem with two key questions:

In the case of a network partition (

**P**), should we favor availability (**A**) or consistency (**C**)?But else, in the absence of partition (

**E**), should we favor latency (**L**) or consistency (**C**)?

Systems can be **PA** or **PC**, and they can be **EL** or **EC**. So, instead of making a single trade-off as in the CAP theorem, PACELC requires us to consider two decisions. These decisions impact how a system behaves under partition and normal conditions. For example:

**Google Spanner**: Prioritizes consistency over availability during partitions (**PC**) and consistency over latency otherwise (**EC**). Spanner is known as**PC/EC**.**Amazon DynamoDB**: Prioritizes availability over consistency during partitions (**PA**) and latency over consistency otherwise (**EL**). DynamoDB is known as**PA/EL**.

But wait… we introduced the PACELC theorem, but we haven’t discussed yet why this extension of the CAP theorem was needed in the first place.

Yesterday in #17: The CAP Theorem, we mentioned that, in practice, it was infeasible for a system not to be tolerant of network partitions. Hence, in essence, the CAP theorem was really about choosing either consistency or availability. This is what the first PACELC branch (“*If yes*”) is about.

Yet, what about normal conditions when there’s no network partition? That’s what the PACELC theorem introduces with the other branch (“*else*”). It helps us reason about the behavior of a system in the **nominal scenario**: should we favor latency or consistency?

**Latency** in the context of the PACELC theorem is an upper-bound limit during which a request should receive a non-error response (e.g., 500 ms). One limitation of the CAP theorem, if not the most important one, is that it doesn’t account for latency, meaning that theoretically, a system could be considered available even if it takes an impractically long time (e.g., 30 minutes) to respond.

This **missing dimension**—latency—filled by PACELC, provides a more comprehensive framework for reasoning about distributed systems, ensuring we consider not only partition scenarios but also the real-time impact of latency on client experiences.

*Tomorrow, we will explore another fundamental concept in databases: the safety and liveness properties.*