PACELC: two questions, not a vendor label

PACELC extends the CAP discussion. If there is a partition (P), a replicated system must decide which operations preserve availability (A) and which preserve a stronger consistency guarantee (C). Else (E), when communication is healthy, replication can still trade lower latency (L) against stronger consistency (C).

The useful unit of analysis is an operation and its configuration. A single product may use synchronous coordination for a payment transition, local bounded-staleness reads for a feed, and convergent updates for preferences. Assigning one permanent two-letter label to a vendor hides those choices.

Partition branch

For a correctness-critical operation, the safe protocol may reject or wait when it cannot reach the required leader, lease holder, or acknowledgement set. That sacrifices CAP availability for that request.

For mergeable data, a reachable component may accept an operation with a unique operation id plus version or causal metadata. The other component can accept a concurrent operation. Recovery then invokes a documented domain merge, a convergent data type, or exposes the conflict. Availability does not make the conflict disappear.

A timeout is not proof that a write failed. Retrying a non-idempotent action with a new identity can duplicate it. The API needs an idempotency key and a status/reconciliation path.

Else branch

Cross-region coordination adds at least communication and processing to the critical path, but there is no universal millisecond constant. Measure RTT distributions, commit latency and tail behavior in the actual regions and failure domains.

A local read can be faster, but its guarantee must be named: eventual, bounded staleness, session read-your-writes, or another contract. “Fast” and “consistent” are not binary implementation flags.

Quorum inequalities describe set overlap, not a full correctness proof. Leaders, version ordering, membership changes, concurrent writes, read repair and acknowledgement semantics still matter.

Scenarios

A correctness-critical write is not acknowledged when the safe commit condition is unavailable.

A mergeable update completes locally and carries metadata for deterministic reconciliation.

A local read minimizes coordination but follows an explicit freshness contract.

The normal path waits for cross-region protocol conditions and pays the measured latency.

The design classifies individual operations rather than labelling an entire product.

Review checklist

• Define the guarantee for each read and write path.
• Distinguish a failed result from an unknown outcome.
• Measure local and remote latency distributions; do not copy a fixed RTT.
• State replication lag objectives and how clients observe stale data.
• Prove retry and reconciliation behavior under duplicates and reordering.
• Test partition detection, healing, membership change and asymmetric reachability.
• Explain whether multi-key transactions add a separate coordination boundary.

Primary sources

• Daniel Abadi, Consistency Tradeoffs in Modern Distributed Database System Design: CAP is Only Part of the Story: https://www.cs.umd.edu/~abadi/papers/abadi-pacelc.pdf
• Gilbert and Lynch, formal CAP model: https://www.cs.princeton.edu/courses/archive/spring21/cos418/papers/cap.pdf
• Herlihy and Wing, formal linearizability definition: https://www.cs.cmu.edu/~wing/publications/HerlihyWing90.pdf