Vibe Engines Learn
System Design Fundamentals  /  CAP & Consistency
Fundamental 01~12 min readIntermediate
Deep Dive

The CAP theorem,
and the spectrum of consistency.

CAP is the most quoted and least understood idea in distributed systems. It's not "pick two of three" — it's a single forced choice that only matters in one specific moment. Here's what it really says, and the consistency models that live underneath it.

01

What CAP actually says

A distributed system tries to offer three things. Consistency — every read returns the most recent write (or an error). Availability — every request receives a non-error response, even if it isn't the latest. Partition tolerance — the system keeps working when the network drops or delays messages between nodes.

The theorem (Brewer's conjecture, proved by Gilbert & Lynch) says you can't have all three at the same time. But the framing "pick two of three" is misleading. In any real network, partitions will happen — cables fail, switches reboot, packets vanish. So partition tolerance isn't something you choose; it's something reality imposes. The actual decision is what to do during a partition: stay consistent, or stay available.

During a partition — you must pick one
CP

Consistency + Partition

Refuse or block requests that can't be confirmed correct. Some nodes go unavailable, but no one ever reads stale data.

AP

Availability + Partition

Answer every request from whatever replica is reachable, even if it's behind. Reconcile the divergence once the partition heals.

There is no "CA" column. A system that gives up partition tolerance is just a single node.
02

Why "CA" is a myth

People often label a single-node SQL database as "CA". That's only true because a single node can't be partitioned from itself. The moment you replicate that database across two machines to survive failure, you've entered the distributed world, and a partition between them forces the same CP-or-AP choice.

So the honest reading of CAP is: P is mandatory, and you trade C against A only when P strikes. When the network is healthy, a well-built system can deliver both strong consistency and high availability — CAP says nothing about the happy path. Which is exactly the gap PACELC fills.

→ Common interview trap

If you say "I'll build a CA system," a sharp interviewer will ask what happens when two replicas can't reach each other. Always frame your answer as CP or AP, and say which operations need which.

03

PACELC — the part CAP forgets

PACELC completes the picture: if there is a Partition, trade Availability vs Consistency; Else (normal operation), trade Latency vs Consistency. The insight is that consistency has a cost even with no failures: to guarantee a read sees the latest write, replicas must coordinate, and coordination takes round-trips. Lower latency means accepting weaker guarantees.

SystemOn partitionElse (normal)Classification
Dynamo / CassandraAvailabilityLatencyPA / EL
BigTable / HBaseConsistencyConsistencyPC / EC
MongoDB (default)ConsistencyLatencyPC / EL
SpannerConsistencyConsistencyPC / EC

Tunable stores (Cassandra, DynamoDB) let you slide this per-query by choosing how many replicas must respond — which connects directly to quorums and replication.

04

The consistency spectrum

"Consistency" isn't one thing. It's a ladder of guarantees, each weaker and cheaper than the one above.

From strongest (most coordination) to weakest (most available)
StrongestLinearizable — behaves like a single copy; every read sees the latest completed write, in real-time order.
↓Sequential — all nodes see operations in the same order, not necessarily real-time.
↓Causal — operations that depend on each other are seen in order; unrelated ones may differ.
↓Read-your-writes — you always see your own latest change (session guarantee).
↓Monotonic reads — you never see time go backwards across reads.
WeakestEventual — replicas converge if writes stop; reads may be stale meanwhile.

Pick the weakest model that still keeps your product correct. A bank balance needs linearizability. A "likes" counter is fine with eventual consistency. A chat app usually wants causal, so a reply never appears before the message it answers.

→ Mental model

Consistency is chosen per operation, not per system. The same database can require a linearizable write for an account balance and serve an eventually-consistent read for that account's activity feed.

05

Tunable consistency & quorums

Leaderless stores let you dial consistency at query time. With N replicas, a write waits for W acknowledgements and a read queries R replicas. If W + R > N, the read set and write set must overlap on at least one up-to-date replica, giving you strong consistency. Lower the numbers and you trade consistency for latency and availability.

Quorum trade-off (N = 3)

W=3, R=1  ·  W+R>N

  • Strongly consistent reads
  • Fast reads, slow writes
  • Write fails if any replica is down

W=1, R=1  ·  W+R≤N

  • Eventually consistent
  • Fast and highly available
  • Reads may be stale

This is the bridge between CAP and the physical mechanics of replication — and when you need a single agreed value rather than a tunable one, you've crossed into consensus.

06

The quorum math, played out

Run the failure case by hand. Three replicas hold x = 1. A client writes x = 2 with W = 1: node A acknowledges, the write returns "success," and A now disagrees with B and C. A read with R = 1 lands on node C — it returns x = 1. Stale, and the client has no way to know.

W=1 write → {A: 2, B: 1, C: 1}   then  R=1 read hits C → returns 1 (stale)

Now the same write with W = 2 (A and B ack) and a read with R = 2 (hits B and C). The read set must include B — a node with the new value — because two sets of size 2 drawn from 3 nodes cannot avoid each other. The read compares versions and returns 2. That's the entire theorem behind tunable consistency:

W + R > N  ⇒  every read set overlaps every write set in ≥ 1 node  ⇒  the latest write is always seen

Every configuration for N = 3, worked out (this table is exhaustively checkable — the runnable proof is below):

WRW+R>3?GuaranteeProfile
11no (2)eventual — stale reads possiblefastest, most available
21no (3)still stale-able — a common misconfigwrite-safe ≠ read-safe
22yes (4)strong — guaranteed overlapbalanced; survives 1 node down
31yes (4)strongfast reads; writes fail if any node down
13yes (4)strongfast writes; reads fail if any node down

Note the trap in row two: W = 2, R = 1 "feels" safe — a majority acked the write! — but 2 + 1 = 3 is not greater than 3, and the single-node read can land on the one replica that missed the write. This is exactly how Cassandra's QUORUM write + ONE read surprises people in production.

RUN IT YOURSELF

Prove W + R > N by brute force

Don't take the overlap rule on faith — enumerate it. This checks every possible write set and read set for a given N, W, R and reports whether a stale read is even constructible. Then it replays the failure story from above. Change N to 5 or 7 and the rule keeps holding — that's why it's a theorem, not a heuristic.

CPython · WebAssembly
See CAP & consistency in real designs
Key-Value Store — tunable W/R quorums Distributed Cache — eventual reads Payment System — strong consistency Google Docs — causal + convergence Stock Exchange — linearizable matching
Frequently asked

Quick answers

What is the CAP theorem?

During a network partition, a distributed system can guarantee either Consistency (every read returns the latest write) or Availability (every request gets a non-error response), but not both. Since partitions are unavoidable, the real choice is CP vs AP.

Why can't a system be CA?

Partition tolerance isn't optional — networks fail. A pure CA system only exists on a single node. Once partitioned, it must drop either availability or consistency, collapsing into CP or AP.

What is PACELC?

If Partition, trade Availability vs Consistency; Else, trade Latency vs Consistency. It captures that stronger consistency costs latency even when nothing has failed.

Strong vs eventual consistency?

Strong (linearizable) consistency means every read reflects the latest write, at the cost of coordination latency. Eventual consistency lets replicas disagree briefly but converge, trading freshness for speed and availability.

Finished this one? 0 / 139 Handbooks done

Explore the topic

See this alongside everything else on the same subject — handbooks, system designs, challenges and tools, in one place.

Distributed Systems

More Handbooks

Explore more from Vibe Engines

Roadmaps →
System Designs →
AI System Designs →
Algorithms →
Labs →
Paper Breakdowns →

Cite this page

Reference it in your work, paper or an AI's context window.

APASingh, S. (2026). CAP Theorem & Consistency Models. Vibe Engines. https://vibeengines.com/handbook/cap-theorem
MLASingh, Saurabh. “CAP Theorem & Consistency Models.” Vibe Engines, 2026, vibeengines.com/handbook/cap-theorem.
BibTeX
@online{vibeengines-cap-theorem,
  author       = {Singh, Saurabh},
  title        = {CAP Theorem & Consistency Models},
  year         = {2026},
  organization = {Vibe Engines},
  url          = {https://vibeengines.com/handbook/cap-theorem}
}