CAP Theorem and PACELC

CAP theorem basics

Consistency — every read returns the latest write or an error. Availability — every request receives a non-error response (not necessarily the latest data). Partition tolerance — the system continues despite network splits between nodes.

In practice, partitions happen. The real choice is CP (refuse writes/reads until consistent) vs AP (serve possibly stale data).

CP vs AP examples

PACELC extension

If Partition → choose A or C (same as CAP). Else → choose Latency or Consistency.

PACELC reminds you that consistency vs latency matters even on a healthy network — cross-region replication lag is not a partition, but reads are still stale.

Consistency models in practice

-- Strong consistency: read from primary
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 'a1';
COMMIT;
SELECT balance FROM accounts WHERE id = 'a1';  -- same connection → latest

-- Eventual: read from replica (may lag milliseconds to seconds)
SET default_transaction_read_only = on;
-- connection to replica.endpoint
SELECT view_count FROM videos WHERE id = 'v_9182';

Choosing for your product

Map consistency to business rules:

Handling partitions in design

# StreamHub feed service — AP-leaning
during_partition:
  strategy: serve_stale_from_local_cache
  max_staleness_sec: 30
  user_message: optional "feed may be updating"

# StreamHub payment adjacency — CP-leaning
during_partition:
  strategy: fail_closed_on_wallet_ops
  fallback: queue intent, reconcile when healed

Document what users experience when the system cannot meet its ideal guarantees.

Common misconceptions