CAP and PACELC Trade-offs

Consistency vs availability under partitions — the database engineer's lens.

Intermediate10 min read

Read these first

Consistent Hashing in Practice

Why this matters

Mislabeling a store as "CP" or "AP" in interviews signals shallow understanding — real systems tune per operation.
Production incidents during regional outages expose whether your consistency choices match user expectations.
VaultCommerce runs CP-ish Postgres for money and AP-ish caches for browse — the mix is deliberate.

App writesINSERT / UPDATE

LeaderPrimary node

Replica 1Read traffic

Replica 2Read traffic

Writes go to the leader; replicas serve read traffic asynchronously.

CAP in plain terms

CAP components

Consistency (C) — every read returns the latest write (linearisable).
Availability (A) — every request gets a response, even if not the freshest.
Partition tolerance (P) — the system continues despite network splits between nodes.

When nodes cannot talk (partition), you must sacrifice C or A. In practice, partitions happen — datacenter links fail, AZs isolate, misconfigured firewalls drop packets.

Java

Partition between EU and US replicas:

CP choice: reject reads/writes until quorum confirms leader
  → VaultCommerce payment service returns 503 (unavailable but consistent)

AP choice: serve stale data from local replica
  → VaultCommerce product browse shows yesterday's price until healed

PACELC — the everyday trade-off

If Partition, choose A or C; Else, choose Latency or Consistency.

Most of the time there is no partition — you still choose how fresh reads must be versus how fast they return.

Aspect	Latency-first (EL)	Consistency-first (EC)
Typical store	DynamoDB (eventual), Cassandra (ONE)	Postgres primary, etcd
Read behaviour	Local replica, may be stale	Quorum or primary, fresher
VaultCommerce path	Recommendation feed, search facets	Checkout, inventory hold
User-visible risk	Stale banner, wrong count	Slower page, occasional 503

Typical store
Latency-first (EL)DynamoDB (eventual), Cassandra (ONE)
Consistency-first (EC)Postgres primary, etcd
Read behaviour
Latency-first (EL)Local replica, may be stale
Consistency-first (EC)Quorum or primary, fresher
VaultCommerce path
Latency-first (EL)Recommendation feed, search facets
Consistency-first (EC)Checkout, inventory hold
User-visible risk
Latency-first (EL)Stale banner, wrong count
Consistency-first (EC)Slower page, occasional 503

Tunable consistency in practice

Cassandra and DynamoDB expose per-request consistency levels:

Java

-- Fast, possibly stale
SELECT * FROM order_events WHERE order_id = ? USING CONSISTENCY ONE;

-- Stronger, crosses replicas
SELECT * FROM order_events WHERE order_id = ? USING CONSISTENCY QUORUM;

VaultCommerce uses QUORUM for support-agent order lookups and ONE for analytics dashboards where five-minute staleness is acceptable.

Mapping stores to CAP/PACELC

Store	Partition behaviour	Normal operation
Postgres (single primary)	Primary unavailable → writes fail (CP)	Strong reads from primary
Postgres + async replica	Split-brain risk without fencing	Fast reads, bounded lag
Redis (single primary)	Failover may lose last writes	Sub-ms, strong per key
DynamoDB	Regional isolation continues (AP)	Tunable per read/write
Elasticsearch	Replica promotion, stale search OK	Near-real-time index refresh

Postgres (single primary)
Partition behaviourPrimary unavailable → writes fail (CP)
Normal operationStrong reads from primary
Postgres + async replica
Partition behaviourSplit-brain risk without fencing
Normal operationFast reads, bounded lag
Redis (single primary)
Partition behaviourFailover may lose last writes
Normal operationSub-ms, strong per key
DynamoDB
Partition behaviourRegional isolation continues (AP)
Normal operationTunable per read/write
Elasticsearch
Partition behaviourReplica promotion, stale search OK
Normal operationNear-real-time index refresh

Labels like "AP database" oversimplify — DynamoDB offers strongly consistent reads per request at double the read cost.

Designing for your consistency budget

Assign each user journey a freshness requirement:

Java

vaultcommerce_consistency_budget:
  checkout_inventory: strong  # postgres row lock
  order_confirmation: strong  # read from primary
  product_reviews_count: eventual  # mongo, 30s lag OK
  search_facets: eventual  # elasticsearch, minutes OK
  session_cart: sticky  # redis, per-user coherence

Quick recall

Everything you need if you only revisit this box.

During a partition, choose consistency or availability — not both.
PACELC adds the latency vs consistency trade-off when the network is healthy.
VaultCommerce: CP for payments, AP/eventual for browse and search.
Tunable stores let you pick consistency per query, not per database label.
Document a consistency budget per user journey before choosing stores.

Test yourself

Answer these before moving on — recall is what makes it stick.