NoSQL Fundamentals: CAP, BASE, Consistency Models
Fast recall
Quick revision
Core answer
Conceptual understanding of NoSQL theory and practical selection across the four data-model families
Treating CAP as a daily trade-off, calling all NoSQL 'eventually consistent', ignoring PACELC's latency-consistency trade-off, and assuming NoSQL always scales better than SQL
Discuss PACELC, tunable consistency, BASE vs ACID in practice, quorum math (W + R > N), and the 2026 Postgres JSONB shift that closed many NoSQL gaps
Interview-ready guide
Interview answer
Start with framing
- NoSQL is four data-model families — key-value, document, wide-column, graph
- Each relaxes a SQL guarantee for horizontal scale, flexible schema, or access-pattern speed
Explain CAP and PACELC
- CAP is a partition-time choice — pick Consistency or Availability
- Real systems experience partitions; they pick CP or AP
- PACELC adds: even without partitions, trade Latency vs Consistency
- Cassandra is PA/EL, CockroachDB is PC/EC, DynamoDB default is PA/EL
Cover tunable consistency
- Modern NoSQL exposes per-query knobs
- Cassandra consistency levels (ONE, QUORUM, LOCAL_QUORUM)
- DynamoDB strong-read opt-in at 2x cost
- MongoDB read/write concerns (majority, linearizable)
- Quorum math — W + R > N produces strong reads
Close with 2026 pragmatism
- Start with Postgres — JSONB and extensions cover most needs
- Specialize when access pattern or scale truly demands
- Polyglot persistence is fine; measure, don't guess
NoSQL Fundamentals: CAP, BASE, Consistency Models
Direct Answer
NoSQL is not one thing — it is four data-model families (key-value, document, wide-column, graph) that each relax a SQL guarantee to gain horizontal scale, flexible schema, or access-pattern speed. CAP says during a partition you pick consistency or availability; PACELC adds: even without partitions you trade latency for consistency. BASE (Basically Available, Soft state, Eventually consistent) is the NoSQL philosophy opposing ACID. Most modern NoSQL offers tunable consistency — Cassandra consistency levels, DynamoDB strong-reads, MongoDB read/write concerns. The real skill is matching access patterns to the right store — Postgres in 2026 covers many cases people historically reached for NoSQL to solve.
Common Mistakes & Pitfalls
Treating CAP as a daily trade-off, calling all NoSQL 'eventually consistent', ignoring PACELC's latency-consistency trade-off, and assuming NoSQL always scales better than SQL
Check your understanding
Answer these without looking back at the article.
- What's the difference between linearizability and causal consistency?
- How does the saga pattern replace 2PC for distributed transactions?
- When does denormalization in NoSQL become a liability?
- Explain how quorum math (W + R > N) produces strong consistency
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.