Recipe

PACELC Theorem Primer

PACELC extends the famous CAP theorem by acknowledging that distributed systems face a second, equally important trade-off when there is no partition. In the event of a network partition (P), a system must choose between availability (A) and consistency (C). Else (E), during normal operation, it must choose between latency (L) and consistency (C). This recipe walks through the model so you can classify Meridian-backed data stores honestly.

1. Read CAP, then keep going

CAP told us that during a partition you must sacrifice either availability or consistency. That is true but incomplete. Real systems spend almost all of their uptime not partitioned, yet still make daily trade-offs between fast replies and strongly consistent reads. PACELC names that second axis explicitly, which is the part engineers actually feel in latency budgets.

2. The four canonical postures

Every store lands in one of four buckets: PA/EL (Cassandra, Dynamo — fast and available, eventually consistent), PA/EC (MongoDB defaults), PC/EL (PNUTS-style), and PC/EC (Spanner, etcd — consistent on both axes, paying latency for it). Knowing your bucket prevents shipping promises the store cannot keep.

3. A decision sketch in code

The branch below is the whole theorem in nine lines. Pin your store on each branch and you have an honest one-page architecture brief.

// PACELC decision sketch
function choose(partition: boolean) {
  if (partition) {
    // P: pick between Availability and Consistency
    return preferAvailability ? "AP" : "CP";
  }
  // ELC: even with no partition, pick Latency or Consistency
  return preferLatency ? "EL" : "EC";
}