CAP and consistency models

System Design · lesson 10 of 32 · 4 min read

Say what a distributed store gives up during a network partition, and name the consistency you need.

Open this lesson in the learning hub

Key points

  • Partitions happen - cables break. CAP asks one thing: when the network splits, do you refuse writes (CP) or accept and reconcile later (AP)?
  • PACELC finishes the sentence: even with no partition, you still trade latency against consistency on every request.
  • Strong (linearizable) means a read always sees the latest write. It costs a cross-node round trip on every operation.
  • Eventual means replicas converge if writes stop. Fine for a like count, wrong for an account balance.
  • The one users notice is read-your-writes: my own post must appear instantly, even if yours takes a second.
  • Quorums let you tune it: with N replicas, R + W > N forces the read and write sets to overlap. Dynamo-style stores expose this per call.

Do not label a system CP or AP. Say which operations need strong reads and pay only for those.

Consistent hashing Queues and async work

This is a reading copy. The full lesson — with the visual explainer, the interactive lab and a Run button for the code — lives in the System Design course, and every lesson in it is listed on the System Design contents page.