Back to roadmap
Module 3 · Consistency & ReplicationDay 02020 min

PACELC and Latency Tradeoffs

Even without a partition, consistency costs latency.

← PreviousNext →
Day 020

PACELC and Latency Tradeoffs

P→A
note
P→C
note
E→L
note
E→C
note
Memory hook

PACELC and Latency Tradeoffs: even without a partition, consistency costs latency

Mental model

choose the failure mode you can explain

Design lens

Async favors latency; sync favors consistency and durability.

Recall anchors
PartitionElse

Why it matters

PACELC extends CAP with the everyday case: outside of partitions, do you favor low Latency (async replication, possible staleness) or strong Consistency (synchronous replication, slower writes)?

Deep dive

Async replication: writes ack on leader; replicas catch up later. Low latency, possible staleness.

Sync replication: writes ack only after replicas confirm. Strong consistency, higher latency, lower availability if a replica is slow.

Real systems often pick per-table, per-region, per-operation — not globally.

Demo / scenario

Postgres primary + 2 read replicas, choosing replication mode.

  1. Async: writes ~5ms, possible 10–500ms staleness on replicas.
  2. Sync (one replica): writes ~10–20ms, no staleness on that replica.
  3. Sync (all replicas): writes block on slowest; tail latency grows.
  4. Common: sync to one same-zone replica, async cross-region.

Tradeoffs

  • Async favors latency; sync favors consistency and durability.
  • Sync to too many replicas hits availability.
  • Per-query consistency level (e.g. read-your-writes) softens the choice.

Diagram

P→A
AP under partition
P→C
CP under partition
E→L
Async, low latency
E→C
Sync, strong
PACELC quadrants.

Mind map

Check yourself

Loading quiz…

Sources & further reading

← PreviousNext →