CAP and PACELC

The idea

Eric Brewer's CAP theorem says that when a network partition occurs, a distributed system must choose between consistency (every read sees the latest write) and availability (every request gets a response). Partitions are not optional in a distributed system, so the real choice is what to give up when one happens.

Daniel Abadi's PACELC extends this: if there is a Partition, choose Availability or Consistency; Else, in normal operation, choose Latency or Consistency. Keeping replicas in step costs round trips on every request, even when nothing is wrong. Abadi argued that this everyday trade-off has arguably shaped database design more than partitions have.

Brewer himself, twelve years on, warned that "pick two of three" is misleading. Partitions are rare, the choice can be made per operation, and both consistency and availability come in degrees.

Why it works

It forces an explicit failure decision. Asking "what should this do during a partition?" turns a hidden default into a design choice.

It names the everyday cost. PACELC reminds you that strong consistency is paid for in latency all the time, not only during failures.

It works at the level of operations. Different data and operations can make different choices within one system.

Where it applies

• Data store selection, where products make different default choices and some can be tuned.
• Multi-region designs, where cross-region round trips make the latency cost obvious.
• Domain design, where business rules decide which data must be strongly consistent.

How to apply

1. List the critical operations. For each, ask what should happen during a partition: fail, or serve possibly stale data.
2. Ask the else question. For each, decide whether lower latency or stronger consistency matters more in normal operation.
3. Choose per use case, not per system. Account balances and stock reservations may need strong consistency; reviews and recommendations rarely do.
4. Match the store and settings. Pick data stores, replication modes and read settings that implement those choices, and write the decisions down.

Example scenario

A retailer ran a single strongly consistent database across regions, so every write, including adding an item to a wish list, paid a cross-region round trip. Pages were slow for customers far from the primary region, and an inter-region network problem took writes down everywhere.

The architects classified operations. Inventory reservations and payments kept strong consistency. Catalogue browsing, wish lists and reviews moved to regional replicas with eventual consistency. Page latency for distant customers fell sharply, and a later network partition degraded checkout in one region rather than the whole site.

Questions to ask

When not to use it

• Single-node systems, where there is no partition to reason about.
• As the only lens on data store choice; durability, operability, cost and query model often matter more.

How it misleads you