Stop 20 · System DesignTopics · 6/15

CAP Theorem

In short

Networks break. When two database nodes can't talk, you must choose: refuse some requests to stay correct, or answer everyone and risk stale data. That choice is the CAP theorem.

A theorem stating a distributed system can only guarantee two of three properties at once during a network failure: Consistency, Availability, and Partition tolerance.

The purple blob holds a phone with a cut cord between two small grocery shops.

Think of it like this

Two branches, cut phone line

A kirana chain has two branches sharing one stock count over the phone. The line goes dead. A customer wants the last bag of rice. Branch A can refuse until the line's back (consistent), or sell it and hope Branch B didn't (available). It can't promise both.

Watch it happen

A partition forces a choice

Customer

Node A

Node B

replicate stock=1

1/5Normally Node A and Node B stay in sync. Both say one bag of rice is left.

The big ideas

What you need to know

Consistency

Every read sees the latest write. One shared truth, no matter which node you ask.

Availability

Every request to a working node gets a non-error answer, even if it isn't the newest data.

Partition tolerance

The system keeps running when messages between nodes are lost. Over a real network, you must handle this.

So really: C or A, during a partition

When the network is fine you can have both. CAP is about what you give up when it isn't.

See it in code

Walk through the code

1// MongoDB lets you choose per operation2await orders.insertOne(order, {3  writeConcern: { w: "majority" }, // wait until most nodes have it4});5 6// Leaning C: read only majority-confirmed data, from the primary7const fresh = await orders.findOne({ _id: id }, {8  readConcern: { level: "majority" },9  readPreference: "primary",10});11 12// Leaning A: any secondary may answer, data may be slightly old13const fast = await orders.findOne({ _id: id }, {14  readPreference: "secondaryPreferred",15});

1/3The write only counts as done once a majority of nodes have it.

Real databases rarely pick one letter for everything. They give you knobs, and you choose per feature how much freshness to trade for speed and uptime.

Save yourself the pain

Common mistakes

Oops

Saying 'my system is CA'.

Do this instead

Over a real network, partitions happen, so P isn't optional. The real choice is C or A while partitioned.

Oops

Treating CAP as one switch for the whole app.

Do this instead

Choose per feature. Payments lean consistent; a like counter or a feed can lean available.

Your mission

Classify your features

~15 min

Quick check

A network partition splits your cluster. Which choice fits a bank balance transfer?

Go deeper

1Explain CAP theorem in your own words with a concrete example.
2Classify a database you know, e.g. PostgreSQL or DynamoDB, by which two properties it prioritizes.
3Understand partition tolerance is essentially mandatory for any real distributed system — the real choice is C vs A.