Step 1 Understand it
The problem it solves. To survive failures and be fast for users everywhere, you keep copies of data on several machines. But copies can't all change at exactly the same instant, and the network between them can break. You must decide what users see in that gap.
New words in this topic (tap one to see what it means)
Watch it happen
Read the animation as text
- Two copies of one account, in London and Paris. Both say £100, and they keep each other in step.
- The network between them breaks: a partition. It WILL happen sooner or later. Now a user in London withdraws £80.
- A CP system (consistent) refuses, because it can't confirm with Paris. Always correct — but some requests fail until the network heals.
- An AP system (available) accepts: London now says £20 while Paris still says £100. Both keep answering — but a second £80 withdrawal in Paris would overdraw the account.
- When the network heals, the AP system must reconcile the two copies. So during a partition the real choice is consistency OR availability.
- PACELC adds: Else, with no partition, waiting for both copies before saying "done" is consistent but slower. Even on a good day you trade latency against consistency.
Picture it
flowchart TD U["User withdraws £80 in London"] --> L["London copy<br/>balance £100"] L ---|"network broken ✗"| P["Paris copy<br/>balance £100"] L --> CP["CP choice: refuse until Paris confirms<br/>always correct, some requests fail"] L --> AP["AP choice: accept, London shows £20<br/>always answers, copies may disagree"]
The idea
When data is copied across machines, the copies can briefly disagree. makes every read return the latest value, but may have to refuse when machines can't talk to each other. always answers, but a read can be briefly out of date. will happen, so the real choice is C or A during a . adds: else (normally), you trade against .
How it works, step by step
- Picture two , in London and Paris, each holding a balance of £100.
- The network between them breaks: a partition. A user in London withdraws £80.
- CP choice: London refuses, or only accepts if it can confirm with Paris. Always correct, but some requests fail until the network heals.
- AP choice: London accepts and records £20, while Paris still says £100. Both keep answering, but a second £80 withdrawal in Paris would overdraw the account. When the network heals, the system must the two.
- With no partition (normal running), waiting for both copies before confirming is consistent but slower. That's the latency-versus-consistency trade-off in PACELC.
Analogy
Two bank branches whose phone line is cut. Either they stop withdrawals until the line is back (consistency), or they keep serving customers and reconcile later, risking an overdrawn account ().
Where the analogy breaks
A bank makes this choice once, as a policy. Real systems choose per operation: a social feed can be eventually consistent while the payment inside the same app must be strongly consistent.
Example
Bank balance: strong consistency (CP). Likes on a post: eventual consistency (AP); nobody minds seeing 1,203 instead of 1,205 for a second.
Must-know points
- C = every read sees the latest write; A = every request gets a non-error ; P = the system keeps working when messages between machines are lost.
- Partitions are unavoidable in distributed systems, so it's CP or AP during a partition.
- Consistency levels: strong, read-your-own-writes, monotonic reads, eventual.
- : with N copies, writing to W and reading from R where W + R > N means every read overlaps the latest write.
- PACELC: even without partitions, stronger consistency costs latency.
- 's C is not 's C (which is about the 's rules and constraints).
Common mistakes
- Calling a system 'CA'. With replicas, partitions can't be wished away.
- Treating CAP as one choice for the whole system, instead of a choice per type of data.
- Confusing CAP's consistency with ACID's consistency.
Trade-offs
- CP: correct, but may reject requests during a partition (bank ).
- AP: always answers, but may return stale data and needs conflict handling (shopping cart, likes).
Step 2 Go further (free, optional)
Optional. The notes above are written to be enough on their own. These free resources give a second explanation and extra practice.
-
Watch
Distributed Systems lecture series: consistency and consensus
Martin Kleppmann, University of Cambridge · free on YouTube
-
Watch
ByteByteGo · YouTube
-
Read
Donne Martin · GitHub, free
Step 3 Practise
Try each exercise yourself first: on paper, out loud or in code. Then open the answer and compare it with yours.
-
ExplainSay it in plain words in under a minute, with no notes.
Explain CAP with the two-bank-branches picture, and why 'CA' isn't a real choice for distributed systems.
Show answer
Two branches of a bank share every account, and the phone line between them is cut (a network partition). A customer asks the London branch to withdraw £80 from an account holding £100. London can't check with Paris. It has two choices:
• Consistency (CP): refuse, or wait, until the line is back. Every answer it gives is correct, but some customers are turned away.
• Availability (AP): pay out and note it down, and sort things out with Paris later. Everyone is served, but Paris still thinks the balance is £100, so the account could be overdrawn twice over.Why "CA" isn't a real choice: CA would mean "consistent and available, as long as there are no partitions". But once data lives on more than one machine, the network between them will fail sometimes; you can't choose to have no partitions. So the real question is only what you do when one happens: refuse (C) or answer (A). A single machine is "CA" only because it has nothing to be partitioned from.
-
DrawSketch the diagram (or class diagram) from memory.
Draw two replicas separated by a partition, and show what a CP system and an AP system each do with a write.
Show answer
The partition is the same in both pictures; the only difference is whether the replica that can't reach the other one keeps accepting writes.
textReplica A ══ ✗ partition ✗ ══ Replica B (London) (Paris) balance £100 balance £100 Write: "withdraw £80" arrives at A CP system A can't confirm with B → refuses (or waits): error to the user → both still say £100: correct, not available AP system A accepts → A says £20, B still says £100 → the user gets an answer: available → copies disagree until the partition heals, then they must be reconciled -
ApplyUse it in a real design question and say exactly where it fits.
Label each as needing strong or eventual consistency: bank balance, Instagram likes, cinema seat booking, profile picture, stock level at checkout.
Show answer
• Bank balance: strong. A stale balance lets someone spend the same money twice.
• Instagram likes: eventual. Seeing 1,203 instead of 1,205 for a second harms nobody, and the counter must stay up under huge load.
• Cinema seat booking: strong. Two people must never both get seat F12; the booking must be checked against the latest state (a , or a conditional write).
• Profile picture: eventual, with one exception: the person who changed it should see their own change straight away (read-your-own-writes). Everyone else can catch up in a few seconds.
• Stock level at checkout: strong at the moment of buying (decrement only if stock > 0, ), so you never sell the last item twice. The "only 3 left" shown while browsing can be eventual. -
Trade-offsSay what it costs, when not to use it, and the alternative.
With N = 3 copies, compare W = 3, R = 1 with W = 2, R = 2. What does each favour?
Show answer
With N = 3 copies, both settings satisfy W + R > N (3 + 1 = 4, 2 + 2 = 4), so every read overlaps the latest write. What differs is speed and what survives a failure.
W = 3, R = 1:
• Reads are as fast as possible: any one copy will do.
• Writes are slow (they wait for the slowest copy) and fail if any one of the three copies is down.
• It favours read-heavy data that is rarely written, where losing write availability briefly is acceptable.W = 2, R = 2:
• Both reads and writes wait for two copies: balanced latency.
• Both keep working with one copy down.
• It favours availability, and workloads with a fair mix of reads and writes. This is the common default (a "quorum" of 2 out of 3).(Going further, W = 1, R = 1 is fastest of all, but 1 + 1 is not more than 3, so reads can be stale: eventual consistency.)
Step 4 Interview-ready, then prove it
Your interview answer
About 20 to 40 seconds, said out loud. Practise it until it sounds like you, not like notes.
It depends on the data. For money or stock levels I'd choose strong consistency, accepting that some requests fail during a partition. For feeds, likes or view counts I'd choose availability with eventual consistency, because a slightly stale number is harmless and the system stays up.
Follow-up questions
Is a single- database CP or AP?
CAP is about distributed systems with replicas. One server has no partition between copies; with replicas, it depends on how replication and are set up.
Explain W + R > N.
If every write reaches W copies and every read checks R copies, and W + R > N, at least one copy you read must have the latest write.
Tick each check when you can do it without notes
A topic is finished when you pass all four checks, not when you finish a video. Be strict: if you needed your notes, it is not ticked yet.
- Explain Say it in plain words in under a minute, with no notes.
- Draw Sketch the diagram (or class diagram) from memory.
- Apply Use it in a real design question and say exactly where it fits.
- Trade-offs Say what it costs, when not to use it, and the alternative.
0 of 4 checks ticked.
Saved in this browser. Back it up or move it to another device.