PACELC Theorem

CAP only describes what happens during a partition — but partitions are rare. Most of your system's life is spent in the no-partition state, where CAP has nothing to say. The real everyday tradeoff there is between latency and consistency. PACELC (Daniel Abadi, 2010) captures both cases: "If Partition then A-or-C; Else L-or-C."

If you can explain PACELC in an interview, you demonstrate that you think about distributed systems beyond the pop-CAP version everyone has memorized.

Partition: if the network is broken between nodes…

Availability: …keep serving reads/writes (may return stale data), OR…

Consistency: …refuse writes until partition heals.

Else (no partition): …

Latency: …serve fast, from the nearest replica (eventual consistency), OR…

Consistency: …coordinate with other replicas to ensure the read is latest (strong consistency, slower).

Every distributed database occupies one of four quadrants: PA/EL, PA/EC, PC/EL, PC/EC.

Even with no partition, multi-region systems face a choice every single read: serve from the local replica (fast, maybe stale) or round-trip to the leader (correct, slow)?

Numbers make this concrete. Your user is in Singapore. Your leader is in Virginia. Round-trip = ~180ms. If you pick EC (consistent reads from leader), every read costs 180ms minimum. If you pick EL (eventual, from Singapore replica), reads cost 1ms — 180× faster — but the replica may be a few milliseconds behind the leader.

A user's "Settings" page probably needs EC (they just changed their password, the next page must show the new state). A user's news feed needs EL (15ms of staleness is invisible; 180ms per read is a disaster). Real systems often pick per-query, not per-system.

News feed picks PA/EL for massive read scale. Typeahead suggestions tolerate milliseconds of staleness (EL) for latency. Google Docs picks PC/EC for collaborative edits — correctness is non-negotiable.