NexisyTech Learningby Nexisy Technologies

CAP Theorem & Consistency

During a network partition, a distributed store must choose between consistency and availability.

Intermediate8 min read3 interview questions

The CAP theorem says a distributed data store cannot guarantee all three of Consistency, Availability and Partition tolerance at the same time.

Networks do fail, so partition tolerance is not optional. The real question is: when nodes cannot talk to each other, do you refuse requests (CP) or answer with possibly stale data (AP)?

Diagram

CP: MongoDB*, HBaseAP: Cassandra, DynamoDB*CA: only without partitionsConsistencyevery read sees the latest writeAvailabilityevery request gets an answerPartition toleranceworks despite network splits* configurable — many stores let you tune per request
Pick two — but since partitions happen, the practical choice is CP or AP.

Key concepts

Strong consistency
After a write completes, every reader sees it. Simple to reason about; costs latency.
Eventual consistency
Replicas converge over time if writes stop. Fast and available; readers may see old data.
Quorum
With N replicas, requiring W writes and R reads where R + W > N guarantees a read overlaps the latest write.
PACELC
Extends CAP: if Partitioned choose A or C; Else choose Latency or Consistency.
ACID vs BASE
ACID transactions favour correctness; BASE (basically available, soft state, eventual consistency) favours availability.

Trade-offs

Benefits

  • Gives a clear framework for discussing data trade-offs
  • Helps choose the right store per use case

Costs

  • Over-simplified: real systems offer a spectrum of consistency levels
  • Says nothing about latency in normal operation (see PACELC)

Use it when

  • Choose CP for balances, inventory, bookings — wrong data is worse than an error
  • Choose AP for feeds, likes, view counts, shopping carts — availability matters more

Common mistakes

  • Calling a single-node database “CA” as if it scaled
  • Assuming eventual consistency means “consistent within a second” — it has no fixed bound
  • Mixing consistency levels without documenting which reads may be stale

Interview questions

Q1Why can’t a distributed system be CA?
Because partitions will happen. When they do, a node must either reject requests to stay consistent or serve possibly stale data to stay available.
Q2With 3 replicas, which quorum settings give strong consistency?
Any R and W where R + W > 3, for example W = 2 and R = 2. Every read set then overlaps at least one replica with the latest write.
Q3Would you use an AP store for a bank balance?
Generally no. Overdrafts from concurrent stale reads are unacceptable, so balances need a CP store or a single-writer design with strong consistency.

Related lessons

Data & Storage

Database Scaling & Replication

From one database server to replicas, partitions and shards — in the order you should reach for them.

Intermediate10 min read Data & Storage

SQL vs NoSQL

Relational, document, key-value, wide-column and graph databases — match the store to the access pattern.

Beginner8 min read Messaging & Microservices

The Saga Pattern

Run a business transaction across services as a series of local steps with compensations.

Advanced9 min read