PACELC

What we're doing: Show that the "Else" branch applies even when a system has never experienced a partition.

Day 1, no partition: a write is sent to a
primary and 2 replicas.
  Option A: primary replies once it has written
    locally.        -> low latency, replicas may
                        lag briefly (chose L)
  Option B: primary waits for both replicas to
    ack before replying.
                     -> higher latency, all copies
                        agree at reply time (chose C)

Day 47, a network partition splits the replicas
from the primary.
  Option A: primary keeps accepting writes anyway.
                     -> stays available (chose A)
  Option B: primary refuses writes until the
    partition heals.
                     -> stops serving (chose C)

The Day 1 choice and the Day 47 choice are made
independently -- a system can pick differently in
each branch.

3

Option A on Day 1 is the "Else" branch of PACELC in action: no partition exists, yet the system still trades away some consistency for lower latency.

11

Day 47 is the classic CAP scenario — a real partition forces a choice between staying available and staying consistent.

19

The point of PACELC: the Day 1 (Else) decision and the Day 47 (Partition) decision are two separate design choices, not one.

Why this works: CAP alone would leave the Day 1 scenario completely undescribed, since no partition is happening — but that ordinary, partition-free case is where a replicated system spends nearly all of its time, so it is the trade-off engineers hit most often in practice.

What we're doing: Trace one write and one read through both the fast/available path and the consistent path, with no partition anywhere.

Setup: 1 primary + 2 secondaries, all healthy,
all reachable. No partition.

WRITE, path 1 (low latency):
  app -> primary: insert({..}, {w: 1})
  primary applies locally, replies "ok"     <- ~5ms
  secondaries catch up asynchronously,
    a beat behind

WRITE, path 2 (consistent):
  app -> primary: insert({..}, {w: 'majority'})
  primary applies locally
  primary waits for 1 of 2 secondaries
    to durably ack
  primary replies "ok"                      <- ~40ms
  (slower: bounded by the slower of the
   two secondaries' ack time)

READ, path 1 (low latency):
  app -> nearest secondary: findOne(id)
  secondary answers from its own copy       <- ~5ms
  (might not yet reflect the write above,
   if that secondary hasn't replicated it)

READ, path 2 (consistent):
  app -> primary: findOne(id)
  primary answers from the source of truth  <- ~15ms
  (guaranteed to reflect any 'majority'-
   acknowledged write)

9

Path 1's write returns after only the primary applies it — fast, but the two secondaries are still catching up when "ok" comes back.

15

Path 2's write blocks on a majority ack (1 of 2 secondaries) before replying — the extra network round trip is the latency cost of that consistency guarantee.

21

Path 1's read goes to the nearest secondary and can return before that secondary has replicated the most recent write.

26

Path 2's read goes to the primary, guaranteeing it reflects any write that was itself acknowledged by a majority — at the cost of that extra hop and no geographic-proximity benefit.

Why this works: Every millisecond in this trace happens with a fully healthy, unpartitioned cluster — the entire latency difference between the two paths is the cost of insisting on stronger consistency, which is precisely the trade-off CAP theorem has nothing to say about.

What we're doing: Walk the checklist end to end for DynamoDB's default configuration, then show how a single flag moves one operation to a different point on the trade-off.

System under evaluation: Amazon DynamoDB (default config)

Q1 - partition behavior:
  DynamoDB is built to keep serving both reads
  and writes during infrastructure/network
  issues within its replication group.
  -> Answer: PA

Q2 - normal-operation default (GetItem, no flag):
  "Eventually consistent" is the default read
  type. Docs: "the responses might not reflect
  the results of a recently completed write."
  Also: eventually consistent reads cost half
  of strongly consistent reads.
  -> Answer: EL

Combined default label: PA/EL

Q3 - per-request override:
  GetItem / Query / Scan accept ConsistentRead:
  true, which returns "the most up-to-date data,
  reflecting the updates from all prior
  successful write operations" for that one call.
  -> That single call moves toward the EC side
     of the normal-operation question, at higher
     cost and latency; it does not change the
     partition-time (Q1) answer at all.

4

Q1 is answered from what the system is designed to do when a partition occurs — DynamoDB favors staying available.

11

Q2 is answered from the default, no-flag behavior of a normal read — eventually consistent is the default and explicitly documented as possibly stale.

21

Q3 shows the checklist applied per-operation: ConsistentRead:true only changes the answer to Q2 for that call, and never touches the Q1 (partition) answer — confirming the two questions really are independent.

Why this works: Running the checklist in order — partition behavior first, then normal-operation behavior, then checking for per-call overrides — is what turns "PACELC" from a memorized acronym into something that produces a specific, defensible label for a specific system and even a specific API call.