What is the CAP theorem's extension — PACELC theorem?

Why Interviewers Ask This

Interviewers ask this to evaluate whether you have the depth of knowledge needed to mentor others and lead technical decisions. The expected answer goes beyond definitions into practical implications and real-world consequences.

Answer

The PACELC theorem extends the CAP theorem by acknowledging that even in the absence of network partitions, a distributed system must trade off between latency (L) and consistency (C). CAP only addresses the partition scenario; PACELC covers normal operations too. PACELC stands for: "In case of Partition (P), a system must choose between Availability (A) and Consistency (C); Else (E), even when operating normally without partitions, a system must choose between Latency (L) and Consistency (C)." Why latency-consistency trade-off? Achieving strong consistency requires coordination — waiting for all replicas to agree before responding (e.g., quorum write). This coordination adds latency. To minimize latency, respond as soon as the local write is confirmed (eventual consistency). System classifications: PA/EL: choose availability during partition, low latency normally. Examples: Dynamo, Cassandra (default). Very fast responses, eventual consistency always. PC/EC: choose consistency during partition, strong consistency normally. Examples: HBase, ZooKeeper, etcd. Slower responses (coordination required), strongest consistency. PA/EC: available during partition, consistent in normal operation. Examples: MongoDB (some configurations), Cosmos DB (strong consistency mode with partition tolerance trade-off). PC/EL: consistent during partition, low latency normally. Rare. Practical value: PACELC is more useful than CAP for designing systems because it acknowledges that latency/consistency trade-off is constant, not just during the rare partition event. Most systems optimize for the EL side since partitions are infrequent.

Pro Tip

Before answering, structure your response: one-line definition → real-world analogy → concrete example from a project. This makes even complex System Design answers easy to follow.