CAP & consistency
In one line
When a network partition splits a replicated system, it must choose between staying consistent (refusing some requests) and staying available (answering with possibly stale data); consistency models describe exactly what readers are guaranteed to see.
What it is
The CAP theorem says a distributed data store cannot guarantee all three of Consistency, Availability and Partition tolerance at once. Here consistency means linearizability: every read sees the latest completed write, as if there were one copy. Availability means every request to a non-failed node gets a non-error response. Partition tolerance means the system keeps working when messages between nodes are lost.
Networks do partition, so in practice the choice is what to do during a partition: CP systems reject or block some requests to stay consistent; AP systems keep answering and reconcile later. PACELC adds the everyday case: Else, when there is no partition, you trade Latency against Consistency.
Consistency models range from strong (linearizable) through causal and read-your-writes to eventual consistency, where replicas converge if writes stop, but reads may be stale in the meantime.
Why interviewers ask
Every design with replicated data has to say what users see after a write and what happens when a data center link fails. Interviewers want you to use CAP precisely (not 'pick two'), match the consistency level to the business need, and know tools like quorums and consensus.
How it works
- 1Replicate data across nodes (often 3) for durability and availability.
- 2When a partition cuts nodes off from each other, a node that cannot reach the others must either refuse the request (choose C) or answer with its local, possibly stale data (choose A).
- 3CP systems use consensus (Raft, Paxos) or majority quorums: a write succeeds only when a majority acknowledges it, so the minority side of a partition cannot accept writes.
- 4Quorum reads and writes: with N replicas, write to W and read from R. If R + W > N, every read set overlaps every write set, so a read sees the latest acknowledged write (assuming versioning picks the newest). Example: N = 3, W = 2, R = 2.
- 5AP systems accept writes on any reachable replica and reconcile later using version numbers, last-write-wins timestamps, vector clocks or CRDTs. Background repair (read repair, anti-entropy) makes replicas converge.
- 6Choose per feature: payments and inventory reservations usually need strong consistency; likes, view counts and feeds tolerate eventual consistency.
Worked example · Quorum read and write with N = 3, W = 2, R = 2
- Replicas A, B, C all hold x = 5 at version 1.
- A client writes x = 7. It reaches A and B, which store version 2 and acknowledge. C is slow and still has version 1. Two acks meet W = 2, so the write succeeds.
- A reader queries R = 2 replicas and happens to pick B and C. B returns x = 7 (v2), C returns x = 5 (v1). The reader takes the highest version, 7, and can repair C in the background.
- Any 2 of 3 replicas must include A or B, because 2 + 2 > 3, so every quorum read sees version 2.
- If instead W = 1 and R = 1 (1 + 1 is not greater than 3), a read from C alone would return the stale 5: faster and more available, but only eventually consistent.
Picture it
Two bank branches lose their phone line. Either they stop letting customers withdraw until the line is back (consistent but unavailable), or they keep serving everyone and sort out overdrafts later (available but possibly inconsistent).
Key patterns
Quorums (R + W > N)
When: Leaderless replicated stores
How: Tune W and R per operation; higher values give stronger reads, lower values give lower latency and higher availability.
Consensus (Raft, Paxos)
When: Metadata, leader election, locks, strongly consistent databases
How: A leader replicates a log to a majority before committing; the minority cannot make progress.
Read-your-writes
When: Users must see their own changes
How: Route a user's reads to the leader for a while after writing, or pin them to one replica.
Conflict resolution for AP
When: Multi-leader or leaderless writes
How: Last-write-wins (simple, may lose updates), vector clocks to detect conflicts, or CRDTs that merge automatically (counters, sets).
Real-world use
Amazon DynamoDB
Reads are eventually consistent by default; you can request strongly consistent reads, which cost twice the read capacity and are not supported on global secondary indexes.
Apache Cassandra
Offers tunable consistency per query, such as ONE, QUORUM or ALL, letting each operation choose its point between latency and consistency.
Google Spanner
A globally distributed SQL database that provides external consistency using Paxos replication and TrueTime clock bounds, accepting higher write latency.
etcd and ZooKeeper
CP coordination stores built on Raft (etcd) and ZAB (ZooKeeper); they hold Kubernetes state, leader elections and configuration, and refuse writes without a majority.
In a project
An event ticketing platform runs in two regions. Overselling seats is unacceptable, but the event listing and 'people interested' counters get huge read traffic.
- Split data by consistency need: seat inventory and orders in a strongly consistent store (a single-leader relational database, or a consensus-based database like Spanner or CockroachDB).
- Reserve a seat with a conditional write (update only if status = 'available'), so two buyers cannot both win.
- Serve event descriptions and interest counters from an eventually consistent, multi-region cache and replicas; a counter a few seconds behind is fine.
- During a region partition, the minority region shows events but disables checkout with a clear message instead of risking double sales.
- Show users their own reservation from the primary (read-your-writes) right after booking.
Impact: Zero oversold seats during a regional network incident, while browsing stayed fast and available everywhere; only checkout in the cut-off region paused for a few minutes.
Trade-offs
Use it when
- Strong (CP): money, inventory, uniqueness constraints, locks, leader election
- Eventual (AP): social counters, feeds, product catalogs, presence, analytics
- Tunable: when different operations on the same data have different needs
Avoid it when
- Strong consistency across distant regions for latency-sensitive reads; every read pays a cross-region round trip
- Eventual consistency where a stale read causes real harm, such as double spending
- Last-write-wins for data where concurrent updates must both survive
Common mistakes
- Saying 'pick any two of three'; partitions are not optional, so the real choice is C or A during a partition.
- Confusing CAP consistency (linearizability) with the C in ACID (constraints hold within a transaction).
- Labelling a whole product CP or AP instead of choosing per operation.
- Forgetting the no-partition trade-off between latency and consistency (PACELC).
- Assuming eventual consistency means 'converges quickly'; it only promises convergence if writes stop.
Interview questions
Quick revision
- CAP: during a partition choose consistency or availability.
- CAP C = linearizability; ACID C = constraints hold. Different things.
- PACELC: else (no partition) trade latency vs consistency.
- Quorum: R + W > N gives overlapping reads and writes.
- CP examples: etcd, ZooKeeper, Spanner. Tunable/AP-leaning: Cassandra, DynamoDB default reads.
- Choose per operation: money strong, counters eventual.
- Conflicts: last-write-wins, vector clocks, CRDTs.
Check yourself
1. During a network partition, what does a CP system do?
2. With N = 3 replicas, which setting guarantees a quorum read sees the latest acknowledged write?
3. Which feature can most safely use eventual consistency?
4. What does the 'C' in CAP refer to?
See it in a full design
These walkthroughs use this lesson.
Saved on this device. Create a free account to keep it on every device.
Practise this with Sam
A real mock interview, out loud, with an honest scorecard. Free to start.