Explain the CAP theorem. Why is "pick two of three" misleading?

CAP says that when a network partition splits a distributed system, it can keep either consistency (every read sees the latest write) or availability (every working node answers), not both. "Pick two" is misleading because you cannot choose to avoid partitions, so partition tolerance is not optional. The real choice is CP or AP during a partition, and with no partition you can have both. The trade-off is correct but sometimes unavailable against always up but possibly stale.

For each of these, choose strong or eventual consistency and say why - a bank balance, a like count, a shopping cart, a seat booking.

Bank balance and seat booking need strong consistency, because a wrong answer double-spends money or double-books a seat, and a brief refusal is better. A like count is fine with eventual consistency, since a slightly old number does no harm and staying up matters more. A shopping cart is usually eventual (always accept an item and merge later), with a strong check at checkout. The trade-off is correctness against availability and latency.

A database has 5 copies. How do you choose W and R, and what does R + W > N guarantee?

With N = 5, a common choice is W = 3 and R = 3, so R + W = 6 > 5. Any read set and any write set must share at least one copy, so a read always includes a copy with the latest write. It tolerates two copies being down for both reads and writes. W = 5 and R = 1 makes reads fast but writes fail if any copy is down. R + W <= N makes reads and writes faster and more available but stale reads are possible. The trade-off is latency and availability against freshness.

In an AP system two users update the same record on different sides of a partition. How do you resolve it?

The simplest rule is last write wins, using timestamps, but it silently throws away one acknowledged write and depends on clocks that can drift. Better options are version numbers or vector clocks to detect true conflicts and ask the application to merge them, or data types built to merge, such as counters and sets (CRDTs). For example, merge two carts by taking the union of items. Which to use depends on how costly a lost update is. The trade-off is simplicity against not losing data.

Design the storage for a social app that has both a like counter and a payments feature. What consistency does each get?

Use different stores for different needs. Payments go in a strongly consistent relational database (or a CP store) with transactions, accepting that a payment may be refused during a partition rather than being wrong. The like counter goes in an eventually consistent, highly available store, with counts updated asynchronously and reconciled later, accepting a slightly old number. Keep the two apart so the cheap, fast path does not inherit the expensive guarantees. The trade-off is running two kinds of storage in return for the right guarantee at the right cost.

Visual, interactive interview prep for DSA and system design

Q: In an AP system two users update the same record on different sides of a partition. How do you resolve it?

The simplest rule is last write wins, using timestamps, but it silently throws away one acknowledged write and depends on clocks that can drift. Better options are version numbers or vector clocks to detect true conflicts and ask the application to merge them, or data types built to merge, such as counters and sets (CRDTs). For example, merge two carts by taking the union of items. Which to use depends on how costly a lost update is. The trade-off is simplicity against not losing data.

Q: Design the storage for a social app that has both a like counter and a payments feature. What consistency does each get?

Use different stores for different needs. Payments go in a strongly consistent relational database (or a CP store) with transactions, accepting that a payment may be refused during a partition rather than being wrong. The like counter goes in an eventually consistent, highly available store, with counts updated asynchronously and reconciled later, accepting a slightly old number. Keep the two apart so the cheap, fast path does not inherit the expensive guarantees. The trade-off is running two kinds of storage in return for the right guarantee at the right cost.

Every lesson is a live simulation
Free, with an account only to save progress
15 to 25 minutes per lesson

Start a free lesson →or browse all topics ↓

Built by TheLearningLoop Team · About us

Lesson preview · Binary search trees

Interactive demo

Search for:

Array · check one by one3 checks

BST · skip half each step3 checks (faster)

Searching for 42: the array checks every slot in turn. The tree follows one path down.

Pick a number above to search for it. Press Pause to stop the animation.

See it
Tweak it
Say it

Choose what to learn

Pick a topic to see its lessons. All topics

Try a simulation now

Which data structure is fastest? It depends on what you ask it to do.

Data Structures & Algorithms: The Big Picture

Every data structure answers one question: which operations must be fast? Every algorithm follows a handful of patterns. Read this before your first lesson.

Read the full post →

Loading…

No data structure is fastest at everything — it depends on the operations you need.
Six structures (array, linked list, hash map, tree, heap, graph) cover most interview problems.
Most interview algorithms follow a small set of recurring patterns.

FAQ

Is it free?

Yes. Every lesson is free. Ads pay for hosting and new lessons, so you never pay. You only need an account to save progress.

Who is it for?

Students learning computing fundamentals from the ground up, and IT professionals preparing for interviews or refreshing core concepts. Each lesson starts with the basics and builds from there.

How is this different from practice sites like LeetCode?

Practice sites check whether your code passes test cases. TheLearningLoop shows why a structure behaves the way it does, so you can reason through a follow-up question instead of reciting a memorised answer.

How long does each lesson take?

Most take 15 to 25 minutes.

CAP Theorem and Consistency

What a distributed system must give up when the network splits. Consistency vs availability, strong vs eventual consistency, and how quorums let you tune the trade-off.

intermediate30 minAsked oftenCap theoremConsistencyEventual consistencyAvailabilityQuorumDistributed systems

Last reviewed 24 Oct 2026 · by TheLearningLoop Team

Progress is saved on this device. Create a free account to keep it everywhere.

On this page ▾

On this page

Key takeaways

When a network partition splits a system, it must choose between consistency (refuse to answer rather than risk a wrong answer) and availability (always answer, possibly with old data).
Partitions will happen, so the real choice is CP or AP. It is not a free pick of any two of three.
Strong consistency means every read sees the latest write. Eventual consistency means copies agree after a while. Quorums (R + W > N) let you tune between them.

Why consistency is a choice, and when it matters

When data lives on several machines, copies can disagree. A write reaches one machine first. A network cable fails, and machines cannot talk to each other. Now a question has two bad answers: refuse to answer until the machines agree, or answer from what you have and risk being wrong. The CAP theorem says that during such a split you must choose.

The two sides give you things interviewers always ask about:

Consistency: every read returns the latest write, as if there were one copy.
Availability: every request to a working node gets an answer, even if the network is broken.

The third letter, partition tolerance, means the system keeps working when the network splits. In a distributed system you cannot choose to avoid partitions, so the real choice is CP (consistent, may refuse) or AP (available, may be stale).

Choose strong consistency (CP) when:

Being wrong is worse than being briefly unavailable: money, stock at checkout, seat bookings, leader election, locks.

Choose availability and eventual consistency (AP) when:

Being down is worse than being slightly wrong: likes, view counts, feeds, shopping carts, DNS, product browsing.

You may not need to choose at all when:

Your data fits on one node (or one primary): there is no partition between copies to worry about. Many products never need more.
You can partition the problem: use strong consistency for the few things that need it, and eventual for the rest.

Try it

Choose what the system favours when the network splits, and whether to cut node C off. Step through ten ticks of writes and reads.

Consistency or availability during a network split

Step 1 of 11 · Press Space to play, arrow keys to step

When the network splits, favour:

Cut node C off from A and B (ticks 3 to 7)

Node A
x = ?

Node B
x = ?

—

Node C
x = ?

No operation yet.

Start: three copies of one value, x. This system favours consistency (CP): if a node cannot reach a majority of the nodes, it refuses to answer rather than risk a wrong answer.

writes rejected:: 0
reads rejected:: 0
stale reads:: 0
writes overwritten:: 0

1 tick = one step of the simulation. A write or read goes through one node. A majority is 2 of 3 nodes. 'Stale' means the answer differs from the latest acknowledged write.

Speed

Things to try:

Untick Cut node C off and run both behaviours. With no partition, both are always correct: no rejections, no stale reads. CAP only bites when the network splits.
Tick the partition with Consistency (CP): the write via C and the read via C are rejected, but no stale answer is ever returned. The system is unavailable to those clients, and correct.
Switch to Availability (AP): nothing is rejected, but 2 reads return stale answers.
Watch the heal step in AP: the copies disagree, "last write wins" picks x = 3, and the earlier acknowledged write x = 2 is overwritten and lost. Always answering has a price.

Consistency choices

Choice	What you get	Good when	Weakness
Strong consistency (linearizable)	Every read sees the latest write, as if one copy existed	Money, stock, locks, anything where a wrong answer is costly	Slower, and refuses requests it cannot confirm during a partition
Eventual consistency	Copies agree after some time if writes stop	Feeds, counters, carts, caches, high availability across regions	Stale reads; concurrent writes need a conflict rule
Read-your-writes (session consistency)	A user always sees their own updates	Profile edits, posting a comment	Others may still see old data for a while
Causal consistency	If B depends on A, everyone sees A before B	Comment threads, replies	More bookkeeping; weaker than strong
Tunable (quorum) consistency	You choose, per request, how many copies must agree	Systems that mix needs, such as Cassandra and DynamoDB	You must pick the numbers well, and mistakes cause stale reads

CP vs AP

CP (consistency over availability): during a partition, nodes that cannot reach a majority refuse requests. Reads are never stale, but part of the system is unavailable. Examples of use: coordination services, ledgers, bookings.
AP (availability over consistency): during a partition, every node keeps answering from its own copy. The system stays up, but answers can be stale and conflicting writes must be merged afterwards. Examples of use: shopping carts, social counters, DNS.

Real systems are not purely one or the other. Many let you choose per operation, and a system can be CP for one table and AP for another.

How quorums work

A quorum is a minimum number of copies that must agree. With N copies, a write waits for W of them to confirm, and a read asks R of them and takes the newest answer.

N = 3 copies.
A write succeeds when W = 2 copies have it.
A read asks R = 2 copies.
Because R + W > N (2 + 2 > 3), any two copies you read must include at least one that has the latest write. So the read sees the newest value.

Changing the numbers changes the trade-off:

W = N, R = 1: writes are slow (all copies must be up), reads are fast.
W = 1, R = N: writes are fast, reads are slow.
R + W at most N: reads can be stale, in return for speed and availability.

In the demo, a majority of 2 out of 3 is the quorum: the side with two nodes can keep working, and the lone node cannot.

A related idea, PACELC, adds that even with no partition there is a trade-off between latency and consistency: waiting for more copies is safer but slower.

Strong vs eventual consistency vs the alternatives

Concern	Strong consistency	Eventual consistency	Single node
Reads see the latest write	Always	Not always	Always
Works during a partition	Only on the majority side	Yes, everywhere	Not applicable
Write and read latency	Higher (must coordinate)	Lower	Lowest
Conflicting writes	Prevented	Must be merged	None
Survives a node failure	Yes, with a majority	Yes	No
Best for	Money, stock, locks	Feeds, counters, carts	Small systems

Use strong consistency where a wrong answer costs money or trust, and eventual consistency where speed and uptime matter more than being instantly current. Do not pay for strong consistency on data that does not need it.

Avoiding a new single point of failure

Strong consistency needs agreement, and agreement has its own weak spots:

The majority. If you lose more than half the nodes, a CP system stops accepting writes. Use an odd number of nodes and spread them over failure zones.
The leader. Many CP systems elect a leader. A slow or flapping leader means pauses. Make sure elections are quick and well tested.
Clocks. "Last write wins" needs a clock, and clocks drift. Prefer version numbers or merge rules for important data.
Conflict handling. In an AP system, merging is part of the design, not an afterthought.

The trade-off you accept: with CP, some requests fail during a split. With AP, some answers are stale or some writes are merged away.

Common mistakes

"Pick any two of three." You cannot avoid partitions, so you choose between C and A only when one happens. Say that.
Using "eventual" as an excuse. Eventual consistency still needs a plan for conflicts and for users who just made a change.
Last write wins by default. It silently loses acknowledged writes and depends on clocks. Use version numbers, merge rules or data types designed for merging.
Strong consistency everywhere. It costs latency and availability. Use it only for data that needs it.
Mixing up the two Cs. The C in CAP (every read sees the latest write) is not the C in ACID (a transaction keeps data rules true).
Reading your own write from a stale copy. A user changes something and sees the old value. Route their next read to a fresh copy.

How to talk about CAP and consistency in an interview

Say what CAP really means: "during a partition you choose between consistency and availability", not "pick two".
Say which data needs which, with reasons: "payments are CP, the like counter is AP."
Name the mechanism: quorums (R + W > N), leader and majority, or last write wins with its risk.
Mention unprompted: what users see during a partition, how conflicts are merged, and read-your-writes for the person who just wrote.
Name the trade-off in one sentence: wrong-but-up against right-but-down.

Where you meet consistency choices in real systems

Every multi-machine database makes this choice, and many let you tune it. Here are three drawn out, the first with configuration you can run, then more examples.

Example 1: Choosing how many copies must confirm a write

A database can acknowledge a write as soon as one machine has it, or wait until other copies have it too. Waiting is safer and slower. PostgreSQL does this with settings for synchronous standbys. Redis has a WAIT command to ask for confirmation from replicas. Open the example below to see the picture and the configuration.

Config: wait for replicas before acknowledging a writeSetup 2 short snippetsCode no code changes

The primary saves the write, sends it to the replicas, and only tells the client it succeeded once enough replicas have confirmed. Fewer confirmations are faster and riskier, more are safer and slower.

# PostgreSQL primary: choose how much safety to buy with write latency.

# 'on' (the default): a commit waits until its log record is safely flushed to disk on the primary.
# With a synchronous standby (below), 'on' also waits for that standby to flush it.
synchronous_commit = on

# Wait for ANY 1 of these standbys to confirm each commit. The names are placeholders and must match
# each standby's application_name. If neither is reachable, commits wait, so choose consistency over availability.
synchronous_standby_names = 'ANY 1 (replica1, replica2)'

# 'remote_apply' goes further: wait until the standby has applied the change, so a read there sees it.
# Other values trade safety for speed: 'off' returns before the flush and can lose the last moments on a crash.

The PostgreSQL settings were loaded by a real PostgreSQL 16 server binary (postgres -C), which printed the values back. The Redis commands were run against a real Redis 7 server, and WAIT confirmed a replica in the earlier primary-replica test. Replica names and numbers are placeholders. Neither tool turns an ordinary setup into a fully strong-consistency system by itself, so read each product's documentation for the exact guarantee.

Example 2: Quorum reads and writes

With three copies, a write that waits for two and a read that asks two always overlap on at least one copy that has the latest value. That overlap is what makes the read fresh.

The write was saved on nodes 1 and 2. A later read asks nodes 2 and 3. Node 2 is in both sets, so the read sees the newest value even though node 3 is behind.

Example 3: Eventual consistency over time

With eventual consistency, a write reaches the nearest copy first. For a short time other copies return old data. If no new writes arrive, all copies converge to the same value. Applications must be fine with that short window.

The write lands on one copy and spreads to the others. Reads in between may return the old value. After a short while every copy agrees.

More real-world scenarios

4. Payments and bank balances

Two people must never spend the same money. Payment systems favour strong consistency, and accept that a transfer may be refused or delayed during a failure rather than risk a wrong balance.

5. Shopping carts

A cart should always accept an item, even if part of the system is down. Amazon's Dynamo design, described in a well-known paper, kept carts available and merged conflicting versions afterwards, so an item the user had removed could sometimes reappear, rather than the cart refusing to work.

6. Likes, views and follower counts

An exact like count matters less than the page loading. These counters are eventually consistent: a number that is a few seconds old is acceptable, and the count settles on the true value.

7. DNS

DNS answers are cached with expiry times. After a record changes, different resolvers return the old or new value until their caches expire, which is eventual consistency at internet scale.

8. Locks and leader election

Services that need exactly one leader or one lock holder use systems built on consensus, such as etcd or ZooKeeper. These favour consistency, so they can pause during a partition but never hand out two locks.

9. Ticketing and stock

Browsing seats or products can be eventually consistent, but the final purchase must check the true remaining stock. Many systems use strong consistency only at the checkout step.

10. Collaborative editing

When several people edit one document, changes arrive in different orders. Techniques such as CRDTs and operational transformation merge edits so every copy ends up the same without a central lock.

Tools and managed services

Kind	Name	Notes
Open source	etcd, Apache ZooKeeper	Coordination stores built for strong consistency and leader election
Open source	Apache Cassandra	Tunable consistency per request (for example ONE or QUORUM)
Open source	PostgreSQL, MongoDB	Settings for how many replicas confirm a write
AWS	Amazon DynamoDB	Eventually consistent reads by default, with an option for strongly consistent reads
Google Cloud	Cloud Spanner	Globally distributed database with strong consistency
Azure	Azure Cosmos DB	Offers five selectable consistency levels, from strong to eventual

The takeaway

Whenever a design spreads data over machines, the first question you ask is what a user should see when the network splits: the right answer later (CP), or a possibly old answer now (AP), chosen separately for each kind of data.

Interview questions

Try answering out loud before you reveal hints. Interviewers care about how you reason, not just the final answer.

1.
Explain the CAP theorem. Why is "pick two of three" misleading?
easy
2.
For each of these, choose strong or eventual consistency and say why - a bank balance, a like count, a shopping cart, a seat booking.
medium
3.
A database has 5 copies. How do you choose W and R, and what does R + W > N guarantee?
medium
4.
In an AP system two users update the same record on different sides of a partition. How do you resolve it?
medium
5.
Design the storage for a social app that has both a like counter and a payments feature. What consistency does each get?
hard

← Previous

Replication and Sharding

Message Queues and Async Processing

↑ Back to top

Next lesson