CAP theorem in plain words, with examples

The CAP theorem is about distributed systems that keep data on several machines. It names three properties:

• Consistency (C): every read sees the latest write, as if there were one copy.
• Availability (A): every request to a working node gets an answer.
• Partition tolerance (P): the system keeps working even when the network between nodes breaks.

The real claim

Networks do fail, so partitions will happen. You do not get to drop P. The theorem says: when a partition happens, you must choose between C and A. It is not "pick any two of three" at all times. When the network is healthy you can have both.

A concrete example

Two data centres each hold a copy of an account balance. The link between them is cut. A user withdraws money at one site.

• Choose consistency (CP): the other site refuses to answer until the link is back. Data stays correct, but some users get an error.
• Choose availability (AP): both sites keep answering and sync later. Nobody gets an error, but two sites might briefly show different balances.

Which systems lean where

• Consistency first: systems used for coordination and money, such as ZooKeeper and etcd, and most relational setups with a single leader.
• Availability first: systems like Cassandra and DynamoDB lean this way by default, and many can be tuned.

Beyond CAP

Even without a partition, there is a trade between latency and consistency. Waiting for every replica to confirm a write is safer but slower. This is described by the PACELC idea.

How to use it

Ask what is worse for this feature: a wrong answer or no answer? A bank transfer needs correctness. A "likes" counter can be a few seconds stale.

Takeaway: CAP is a choice you make for failure situations, per feature, not a label on a database.

---

Part 3 of 15 in the System Design series. Previous: Latency vs throughput: the two numbers every system design starts with.