2026-06-08
CAP told you that during a network Partition, you pick Availability or Consistency. That's true but incomplete — partitions are rare. What about the 99.9% of the time when the network is fine? PACELC fills the gap: if Partition, then A or C; Else, then Latency or Consistency.
The "ELC" half is the part that actually shapes your day-to-day system behavior. Even with a healthy network, a distributed database must choose: do I wait for replicas to acknowledge a write (consistency, higher latency), or do I respond immediately and let replicas catch up (low latency, possible stale reads)?
Every distributed database falls into one of four buckets:
Concrete example. You're picking between DynamoDB and Spanner for a user profile service. Both survive partitions. CAP says DynamoDB is AP and Spanner is CP — but that's not the whole story. PACELC tells you DynamoDB is EL: a single-region read is ~5ms because it returns from the nearest replica without coordinating. Spanner is EC: every strongly consistent read involves a Paxos quorum, so you're looking at 10–100ms depending on geography. If your profile reads happen on every page load, that latency difference compounds into a user-visible problem long before any partition occurs.
Rule of thumb. Estimate your latency budget: (reads per request) × (replica coordination cost). If a request makes 20 reads and your EC store costs 15ms per read versus 2ms for an EL store, you've burned 260ms on consistency you may not need. For shopping carts, social feeds, and analytics: EL is almost always right. For balances, inventory counts, and authorization: EC earns its keep.
The deeper lesson: consistency isn't free even on a perfect network. CAP's framing makes it feel like consistency only costs something during failures. PACELC makes the everyday tax visible, and that's the tax you'll actually pay.