When I sit down with new engineers, we often start by discussing the CAP theorem (Consistency, Availability, Partition tolerance) to explain trade-offs in distributed systems. For years, it was the standard framework, but relying on it alone leaves engineers unprepared for the nuances of modern System Design.
The CAP theorem tells us that during a network partition (P), a system can guarantee at most one of consistency (C) or availability (A). Consistency here means that every read reflects the most recent write (linearizability), which differs from ACID consistency in databases. While this model is useful, powerful, it focuses only on partitions and doesn’t address other trade-offs, like latency vs. consistency during normal operations.
These limitations show up in real-world systems handling high traffic, where latency and consistency can conflict even without network partitions, and CAP offers no guidance on how to handle this. In such situations, the PACELC theorem provides a framework to capture trade-offs in both normal operation and failure scenarios. Let’s look at how PACELC fills this gap in more detail in the next section.
From CAP to PACELC
PACELC (Partition, Availability, Consistency, Else, Latency, Consistency), introduced in 2010, extends the CAP theorem by emphasizing that trade-offs in distributed systems occur during network failures and under normal operation. Specifically, it highlights that a system still faces a trade-off between latency and consistency even without a partition.
In other words:
If there is a partition (P), a system cannot guarantee both availability (A) and consistency (C). In practice, its design determines which one it prioritizes, which is represented as PA/C.
Else (E), when the system is operating normally, it must choose between latency (L) and consistency (C), which is represented as EL/C.
By capturing both the PA/C trade-off during failures and the EL/C trade-off during normal operation, PACELC offers a more comprehensive model for understanding system behavior in all conditions. This becomes clearer in the next section, as we walk through a concrete example.
Breaking down PACELC in plain language
To make PACELC concrete, I often use the example of a ticket booking system.
The first half, PA/C, is about crisis management. Imagine the system runs into a network partition, where not all servers can talk to each other.
In that situation, one option is to keep the system available (PA) and continue selling tickets. The downside is that the servers may fall out of sync, and two people could buy the same seat. That creates confusion, refund requests, and a poor customer experience.
The other option is to pause sales until the servers catch up with one another (PC). This preserves data integrity but results in downtime, temporarily preventing customers from booking tickets.
Note: In modern systems, partition tolerance is not optional. You design with the assumption that partitions will happen. The real choice is between availability and consistency when they do.
The second half, EL/C, is about normal operations. Even when the system runs smoothly, it must choose between latency and consistency. The system can instantly confirm a booking, favoring speed (EL). However, this introduces a risk of race conditions, where two servers attempt to book the same seat simultaneously without proper coordination, potentially leading to conflicts.
Alternatively, coordinating with all replicas (EC) can take longer, ensuring correctness at the cost of slower responses.
These trade-offs are visually represented in the illustration below:
Most systems spend their time in the “Else” state, balancing speed against correctness. This is why PACELC offers a more practical framework than CAP alone.
Now that we’ve unpacked PACELC with a concrete example, let’s shift to how I help new engineers internalize these trade-offs.
How I explain it to new hires
When onboarding engineers, I aim to help them develop an intuition for system trade-offs, not just memorize the theorem. As outlined below, I use a structured, interactive approach that moves from theory to practice through concrete examples and exercises.
Starting with CAP: I introduce partitions through the booking scenario, showing the choice between availability (keep selling tickets) and consistency (pause sales). This gives everyone a shared baseline.
Extending to PACELC: I highlight that trade-offs don’t disappear when systems are healthy. Using the “Else” part of the booking example, we look at latency (confirming the booking immediately) vs. consistency (checking seat availability across all servers first).
Using interactive scenarios: I give them other real-world problems once the basics click, like designing a social media feed. We debate whether updates are more important to appear instantly (latency) or in the same order for everyone (consistency).
Visualizing decisions: Together, we sketch how a user’s request moves through the system and mark the points where trade-offs between speed and consistency appear. This makes the choices easier to grasp.
5.** Assigning practice:** Finally, I ask them to design a small system, such as a URL shortener or a notification service, and justify their PACELC choices. Reviewing designs as a group reinforces that there is no single right answer, only trade-offs aligned with goals.
These steps help new engineers move beyond definitions and see how PACELC shapes real design choices, preparing them to make informed trade-offs in their work.
Interview insight: PACELC often appears in senior-level System Design interviews. Strong responses reflect an understanding of trade-offs during failures and normal operation and show alignment with business goals, such as consistency for ticketing vs. latency for a social feed, including examples or diagrams that highlight practical understanding beyond theory.
After building intuition through examples and exercises, the next step is seeing how these trade-offs play out in real-world systems.
PACELC in real-world systems
PACELC is a practical framework for understanding how major databases and services balance consistency, availability during network partitions, and consistency and latency under normal circumstances. Knowing where a system falls on the PACELC spectrum helps you choose the right tool for the job.
Let’s look at some real-world systems and how they map to PACELC categories:
PC/EC systems (strictly consistent): These systems maintain consistency during network partitions and under normal operation. They prioritize correctness even if it means higher latency or downtime. For example, Google Spanner and etcd (which uses Raft and blocks during partitions and even leader elections). These are well-suited for banking, inventory, and other domains where errors are unacceptable, though the coordination comes with higher latency.
PA/EL systems (availability and low latency): These systems remain available during partitions and are fast under normal operation, favoring availability and performance over strict consistency. For example, Amazon DynamoDB and Apache Cassandra. These are ideal for e-commerce carts or social feeds where speed is more important than strict consistency.
Note: PC/EL systems, which are consistent during partitions but optimized for latency otherwise, are rare in practice. Similarly, PA/EC systems, which stay available during partitions but enforce strict consistency otherwise, are also uncommon.
All of these categories come together visually in the quadrant diagram below.
Let’s now consider what this all means for system designers today.
Why does PACELC matter for system designers today?
Understanding and applying PACELC shows engineering maturity. It shifts thinking from absolutes to trade-offs, essential in today’s distributed systems. It also provides practical guidance for System Design interviews and real-world architecture decisions.
The next step is recognizing that every system requires context-specific decisions rather than rigid rules. By focusing on context rather than rigid rules, teams can tailor architectures to their specific needs, which is a quality I particularly value in senior engineers and technical leads.
Ultimately, PACELC helps build resilient, scalable, and user-aligned systems. It fosters deliberate, thoughtful engineering where decisions are driven by priorities, not dogma, enabling systems that remain reliable as they grow over time.
Top comments (0)