PACELC Theorem

The PACELC theorem, proposed by Daniel Abadi in 2012, extends the CAP theorem to address a critical gap: what trade-offs does a distributed system face when there is no partition? CAP tells us that during a partition we must choose between availability and consistency, but partitions are rare events. For the vast majority of operating time, the system is healthy -- and during that time, the dominant trade-off is between latency and consistency. PACELC captures both scenarios in a single framework: if Partition, choose A or C; Else, choose L or C.

The 'Else' clause is where PACELC becomes genuinely useful for system design. Synchronous replication guarantees that all replicas have the same data before acknowledging a write, providing strong consistency (EC) but adding network round-trip latency to every operation. For a system replicating across regions, this can mean 50-200ms added to every write. Asynchronous replication acknowledges writes immediately on the primary and propagates changes in the background, providing low latency (EL) but allowing replicas to serve stale data during the replication window. This latency-consistency trade-off affects every single request, not just requests during partitions, making it far more impactful on user experience and system performance.

PACELC classifies systems into four categories based on their choices in both scenarios. A PA/EL system (like DynamoDB or Cassandra in default configuration) chooses availability during partitions and low latency during normal operation -- it optimizes for responsiveness at the cost of consistency in both cases. A PC/EC system (like Google Spanner) chooses consistency in both scenarios -- it will sacrifice availability during partitions and accept higher latency during normal operation to guarantee linearizable reads and writes. A PA/EC system (like MongoDB with majority write concern) provides availability during partitions but enforces consistency during normal operation. These classifications are more descriptive than CAP's binary CP/AP labels because they capture the full spectrum of design decisions.

Understanding PACELC changes how you approach system design conversations. Instead of asking 'is this system CP or AP?' -- which only matters during rare failure events -- you ask 'what latency am I paying for consistency during normal operation?' For a payment processing system, paying 50ms extra per transaction for global consistency (PC/EC) is worthwhile because incorrect balances are unacceptable. For a social media feed, serving slightly stale content with sub-10ms reads (PA/EL) is the right choice because users will not notice a post appearing 500ms late, but they will notice a 200ms page load. PACELC makes these everyday design decisions explicit.

Consider a global news wire service with offices in New York and London. During normal operation (Else clause), the editors face a choice: publish stories instantly to the local office and sync later (EL -- readers see news faster but the two offices may briefly show different versions), or wait for both offices to confirm they have the same version before publishing (EC -- slower but globally consistent). During a transatlantic cable outage (Partition), they choose between: keep publishing locally and merge later (PA -- available but inconsistent), or halt publication until the link is restored (PC -- consistent but unavailable). PACELC captures both decisions: the news wire is PA/EL if it prioritizes speed in both scenarios.