← System Design Hub
System Design · Guide

CAP Theorem

Consistency, availability, partition tolerance trade-offs.

— min read System Design

Theory

During a network partition you cannot have perfect consistency and perfect availability — design per operation, not globally.

The CAP theorem states that during a network partition, a distributed system cannot simultaneously guarantee both Consistency (all nodes return the same data) and Availability (every request gets a response). Partition tolerance is non-negotiable in real networks.

CP systems (etcd, ZooKeeper, HBase) sacrifice availability during partitions to keep consistency. AP systems (Cassandra, DynamoDB, CouchDB) stay available and reconcile conflicts later via eventual consistency.

PACELC extends CAP: under partition choose A or C; else (normal operation) choose Latency or Consistency. Most production databases offer tunable knobs (Cassandra consistency levels, DynamoDB strong vs eventual reads) rather than fixed CAP corners.

Production rollouts require idempotent automation, peer review, staged apply, and documented rollback — treat changes as production code.

Interviewers want STAR stories linking CAP Theorem to measurable outcomes: fewer outages, faster deploys, lower cost, or reduced toil.

Architecture Diagram

Network partition
         |
    +----+----+
    v         v
 Node A      Node B
 (CP path)   (AP path)
 strong      stale OK
 consistency  responses

Examples

bash 
# CAP Theorem
# Consistency, availability, partition tolerance trade-offs.
# Validate in staging before production rollout.

Interview Questions

State CAP formally?

If partition happens, choose C or A; partition tolerance is mandatory in distributed systems.

CP example?

Zookeeper, etcd — refuse writes or reads that cannot be linearizable during partition.

AP example?

Cassandra, Dynamo — accept writes with eventual consistency across replicas.

Is CAP a false trichotomy?

Modern systems tune consistency per request (R/W quorums) — CAP guides thinking, not rigid labels.

PACELC extension?

If Partition: A vs C; Else: Latency vs Consistency — covers normal operation trade-offs.

Interview tip?

Relate CAP choice to product requirements (banking vs social feed).

Best Practices

  • Treat CAP Theorem config as code with review and CI validation.
  • Define SLOs and dashboards before production cutover.
  • Document rollback and ownership for on-call.
  • Use least privilege for credentials and secrets.

Common Mistakes

  • Running CAP Theorem in prod without staging parity.
  • No monitoring on golden signals after changes.
  • Skipping backup/state export before major upgrades.
  • Alert fatigue without actionable runbooks.

Trade-off Analysis

CAP Theorem improves consistency, availability, partition tolerance trade-offs. but adds operational and cognitive complexity — justify with load and team size.

Favor simplicity until metrics (p99 latency, error rate, cost) prove the pattern necessary.

Every redundancy layer trades capital/operational cost for availability — align with explicit SLO targets.

Document accepted inconsistency windows and recovery behavior before production cutover.

Cheat Sheet

CConsistency
AAvailability
PPartition tolerance
QuorumR+W > N
PACELCLatency vs C when no P

Practical Exercises

Classify stores

Label Postgres, Redis, Cassandra on CAP spectrum with caveats.

Partition drill

Describe behavior when AZ link fails for 3-node cluster.

Product pick

Choose CAP bias for inventory vs analytics dashboard.

← Scalability

Related topics