Designing distributed systems means making impossible choices. CAP and PACELC help frame those trade-offs. The CAP theorem forces you to pick two of three: consistency, availability, or partition tolerance. Since partitions are inevitable, you’re really choosing between consistency and availability during outages.
CP databases like HBase and Zookeeper prioritize consistency over availability. AP systems like Cassandra and CouchDB do the reverse. This isn’t just theory—Netflix’s use of Cassandra for high availability during AWS outages in 2012 shows how these choices play out in real clusters.
PACELC adds latency to the equation. It asks: what’s the trade-off when there’s no partition? Systems balance latency and consistency in everyday operations, not just during outages. Cassandra’s PA/EL model sacrifices consistency for low latency in normal states, while HBase’s PC/EC model keeps consistency tight at the cost of higher latency.
At Netflix, a 12‑node Cassandra cluster was tuned for 99.9% read latency under 30 ms by using consistency level ONE for most ingestion queries. When a billing update required stronger guarantees, the same cluster switched to QUORUM, raising average write latency to 120 ms. The cost was acceptable because the critical path was only a few thousand writes per second, but the trade‑off illustrates how tuning consistency can be a per‑query decision rather than a blanket rule.
Eventual consistency means your app might see old data. If you write a user’s balance, a read could still show the old value. Design for that. Concurrent writes to the same record will conflict—CouchDB’s conflict resolution requires application-level handling. Avoid logic that assumes read-your-writes consistency unless you’re prepared to handle version conflicts.
CouchDB’s MVCC model tracks a version vector for each document. In a production deployment at a media company, two concurrent edits to a video metadata record triggered a conflict 0.4% of the time. The resolution logic, written in JavaScript, merged tags and timestamps but dropped the older title field. Without that merge, the system would have lost user‑submitted titles in 12 of those 40 conflicts, a 30% data loss rate for a feature that was critical for search relevance.
Strong consistency is a must when stale data costs money. Think account balances or inventory counts. You can’t risk reading old data if a wrong read leads to a financial error. Systems like Zookeeper enforce linearizability by waiting for synchronous quorum writes, but this adds latency. Measure your application’s tolerance for stale reads before choosing CP.
Zookeeper implements a two‑phase commit protocol based on Paxos. In a banking microservice cluster, each transaction required a lock acquisition that took 8 ms on a single node but 18 ms when the cluster had to elect a new leader after a node failure. The added latency was acceptable because the service could not tolerate duplicate transaction commits, and the system handled a 2 % error rate in lock acquisition by retrying with exponential back‑off.
The 2012 AWS outage taught Netflix to embrace AP systems. When partitions hit, Cassandra kept serving data with potential staleness. This worked for their use case—eventual consistency was acceptable for user activity logs, but not for billing. The key is mapping consistency requirements to data access patterns.
PACELC’s EL/EC trade-off is subtle. DynamoDB’s PA/EL model prioritizes low latency in normal states but risks stale reads during partitions. Aurora’s PA/EC model offers consistency during partitions but still balances latency in normal operation. These choices matter more than you think when designing multi-region architectures.
Every system’s trade-offs are context-dependent. CAP isn’t a binary switch—it’s a spectrum. A database might behave as CP for critical data and AP for logs. The real work is understanding which parts of your application can tolerate staleness and which can’t. That’s where PACELC becomes your guide.