Skip to content
←System Design

// System Design · 03

CAP Theorem

Network partitionleads toPick consistency or availability

During a partition, you can't fully have both at once.

How it fits together

CAP Theorem structureNode Ax = 1 (unchanged)CP: refuses writesPartition«client»ClientNode Bx = 2 (accepted)AP: reconcile later1 write x = 2CP: reject2 AP: acceptlink down
uses / callsfails / error pathcreates· numbered steps replay in order
  • Client uses / calls Node A (1 write x = 2)
  • Node A fails / error path Client (CP: reject)
  • Client creates Node B (2 AP: accept)
  • Node A fails / error path Partition (link down)
  • Partition fails / error path Node B

Spot it

  • Nodes or regions can lose contact with each other
  • Debating whether a stale read is acceptable
  • Choosing a distributed database

It costs

CP refuses requests to stay correct; AP answers but may be wrong for a while.

Go deeperThe full explanation and what to ask for · 1 min readExpand

Partitions are not optional in a distributed system, so the real choice is between C and A while one is happening.

CP systems (etcd, ZooKeeper) refuse to answer rather than risk divergence. AP systems (Cassandra, DynamoDB by default) keep answering and reconcile afterwards.

PACELC adds the everyday case: if Partitioned, choose A or C; Else, choose Latency or Consistency. Most of the time you are trading latency, not availability.

Ask for it

  • CP
  • AP
  • partition tolerance
  • quorum
  • PACELC

For this data, during a network partition should we reject writes (CP) or accept them and reconcile later (AP)? List which entities need which, and the conflict resolution for the AP ones.

Connects to