design·lab

Distributed systems

CAP & Consistency

When a network partition hits replicated data, you can't stay perfectly consistent and fully available at the same time — CAP forces the choice.

✗ Problem

Networks split. Replicas can't both wait and answer.

Data is replicated across nodes for availability and scale. But networks drop messages — a partition can cut nodes off from each other at any moment.

function write(key, value) {
  // this replica can't reach the others right now
  if (linkIsDown) {
    // wait for the others to ack → correct, not available
    // answer anyway right now  → available, maybe wrong
  }
}
During a partition you must choose: stay perfectly consistent and risk being unreachable, or stay available and risk serving stale data.
✓ How it works

CAP: pick two — but P isn't optional

Consistency, Availability, Partition-tolerance. Real networks partition, so P is mandatory — the actual choice is C vs A while the partition lasts.

C
Consistency
A
Availability
P
Partition-tolerance
Node A
✗
Node B
🔒 CP — reject or stall requests on the cut-off side. Always correct, sometimes unavailable.
🌐 AP — answer with what you have. Always available, may be stale until reconciled (eventual consistency).
✓ See it live

Cut the link — read Node B in CP vs AP mode

Pick a mode, partition the network, write to Node A, then read from Node B. Heal the link to see reconciliation.

Node A
v0
↔
Node B
v0

Ready — try writing, then partition and read.

✓ Takeaway

Choose per use case, not once and forever

  • Partitions are unavoidable — the real decision is CP or AP, made per use case: a bank balance wants CP, a social feed wants AP.
  • Consistency is a spectrum — from strong (linearizable) down to eventual, with options like read-your-writes and causal consistency in between.
  • Reconciliation resolves conflicts after a partition heals — last-write-wins, vector clocks, or CRDTs.
  • Availability here means "every request gets a response" — not the same as uptime SLAs.
🎯 Combines / relates: eventual consistency is what makes event-driven, CQRS and sagas necessary — they embrace it instead of fighting it.
Back to all topics →