CAP & PACELC

CAP & PACELC

CAP says that when the network splits replicas apart, a store must choose — refuse some requests to stay consistent, or keep answering and risk old or conflicting data. It's often told as "pick two of three", but splits happen whether you pick them or not, so the real choice is only what to do during one. PACELC adds the everyday half — even with no split, a consistent answer across regions means waiting for a far copy (slower), and a fast one means a nearby copy that may be behind. Most stores let you make that choice per request.

Use when

Deciding what each operation does when a region or a replica can't be reached — wait, refuse or answer stale · Reading a database's marketing label ("CP", "AP", "CA") and asking what it really promises · Weighing the latency of consistent cross-region writes against stale reads in normal running

Avoid when

Labelling a whole system CP or AP instead of naming its consistency model per operation (core/consistency-models) · Treating CAP as the only trade — latency, crashes and transactions matter more on most days

Trade-offs

Choosing consistency in a partition means some users get errors or timeouts until it heals · Choosing availability means divergent copies that must be merged or compensated afterwards · With no partition, consistent writes pay round trips to far replicas; fast ones risk stale reads

Requires

Consistency models: strong to eventual