# The PACELC Theorem

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, 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.

*This post is taken from **The Coder Cafe** newsletter (**issue #18**).*

*Feeling overwhelmed by the endless stream of tech content? At The Coder Cafe, we serve one essential concept for coders daily. Written by a senior software engineer at Google, it’s perfectly brewed for your morning coffee, helping you grow your skills deeply.*