PACELC

Key features

• CAP's trade-off (Availability vs Consistency) only applies while a network Partition is actually happening.
• PACELC adds the "Else" branch: even with zero partitions, a system still trades Latency against Consistency on every request.
• The two branches are independent — a system's partition-time choice and its normal-time choice do not have to match.
• Systems are commonly labeled with both branches at once: PA/EL (available + low-latency, weaker consistency) or PC/EC (consistent in both cases, at the cost of availability or latency).
• Daniel Abadi proposed PACELC in a 2010 blog post and formalized it in a 2012 paper; the reasoning was later given a formal proof by Wojciech Golab in 2018.

Command

PACELC:
  if Partition:
    choose Availability or Consistency   (this part is CAP)
  else (no partition, normal operation):
    choose Latency or Consistency        (this part is new)

Common labels combine both branches, e.g.:
  PA/EL — available under partition, low-latency normally
  PC/EC — consistent under partition, consistent normally

Key features

• MongoDB's write concern w:1 only waits for the primary to apply a write, returning fast; w:"majority" waits for a calculated majority of data-bearing replica set members to durably acknowledge it, which is slower.
• In a 3-member replica set, w:"majority" needs 2 of 3 members to ack; in a 5-member set, 3 of 5 — more members required raises latency further.
• Reading from the nearest replica (rather than the primary) lowers read latency but risks returning data older than the replica's current replication lag.
• DynamoDB's eventually consistent reads (its default) can be measurably faster and cost half as much as its strongly consistent reads, which always return the most recent successful write.
• None of this requires a network partition — every one of these trade-offs is made continuously, during fully normal operation.

Command

// MongoDB — the same insert, two latency/consistency points
db.orders.insertOne(doc, { writeConcern: { w: 1 } });          // fast
db.orders.insertOne(doc, { writeConcern: { w: 'majority' } }); // durable, slower

Key features

• Step 1: identify the partition-time behavior — does the system keep accepting requests (PA) or refuse/block until the partition heals (PC)?
• Step 2: identify the normal-operation behavior on the specific read or write path being evaluated — low latency by default (EL) or wait for stronger consistency by default (EC)?
• The two answers are independent: a system can mix them, e.g. DynamoDB defaults to fast eventually-consistent reads (EL) but also offers an opt-in strongly consistent read (moving that specific path toward EC).
• Because PACELC is per-operation in systems with tunable consistency, the honest answer is often "it depends on the configuration used for this specific request," not one fixed label for the whole system.
• Classic literature examples: early Dynamo, Cassandra and Riak are commonly cited as PA/EL; traditional single-leader relational databases like PostgreSQL and MySQL Cluster, along with Bigtable and HBase, are commonly cited as PC/EC.

Command

PACELC evaluation checklist for a replicated system:

1. Partition question:
   Under a network partition, does it stay
   available (PA) or stay consistent (PC)?

2. Normal-operation question (per read/write path):
   With no partition, does the default favor
   low latency (EL) or consistency (EC)?

3. Check for per-request overrides:
   Can a specific call opt into the other choice
   (e.g. a "strongly consistent" flag)?

Combine 1 + 2 into a label: PA/EL, PC/EC, PA/EC, PC/EL.