NoSQL Fundamentals — CAP, BASE & Eventual Consistency
NoSQL (Not Only SQL) databases abandon the rigid relational model to achieve horizontal scalability, flexible schemas, and high availability at internet scale.
Learning objectives
- State the CAP theorem precisely, and explain why it's a choice under network partition specifically, not a general trade-off at all times.
- Explain what BASE trades away from ACID, and why that trade can be the right one for certain systems.
- Describe eventual consistency in terms of a concrete scenario where two readers briefly see different answers.
📖 Story
Imagine a bank with branches in Mumbai and New York, each keeping its own copy of every account balance, kept in sync by a link between the two cities. One day, that link goes down — a network partition. Each branch can still serve customers on its own, but they can no longer talk to each other to agree on the current balance. Right now, in this exact moment, the bank has to make a choice: either branch keeps operating and answering customers (favoring Availability), accepting that the two branches' numbers might briefly disagree, or one branch refuses to answer at all until the link is restored (favoring Consistency), guaranteeing correctness at the cost of turning customers away.
What CAP actually says
The CAP theorem states that during a network partition, a distributed system can guarantee at most two of three properties: Consistency (every read sees the most recent write, everywhere), Availability (every request gets a response, even if it's not the latest data), and Partition tolerance (the system keeps working despite network failures between nodes). Crucially — and this is the detail almost every simplified explanation skips — this choice only has to be made during an actual partition. Partition tolerance isn't really optional for any real distributed system (networks fail; that's a fact of physics, not a design choice), so in practice CAP is really about: when the network does split, do you choose C or A?
BASE — the trade-off NoSQL systems often choose
Many NoSQL systems favor availability, and describe their consistency model as BASE: Basically Available (the system responds, even during a partition), Soft state (the data may not be immediately consistent everywhere), Eventual consistency (given enough time with no new writes, every copy converges to the same value). This is a genuinely different guarantee than ACID's immediate, all-or-nothing consistency — not a lesser one across the board, just one that trades immediate correctness for continuous availability, which is exactly the right trade for some systems (a social media "like" count) and the wrong one for others (a bank balance).
Eventual consistency, concretely
If you write a new value to one replica and immediately read from a different replica before that write has propagated, you can briefly get the old value back — not because anything is broken, but because "eventual" is doing real work in that name: given a little time, and no further writes, every replica will converge to the same answer.
Replication, underneath eventual consistency
Most NoSQL systems that favor availability replicate a write asynchronously — the write is accepted and acknowledged by one node (or a small quorum of nodes) immediately, then propagated to the remaining replicas in the background, on their own schedule. The gap between "write acknowledged" and "every replica has the new value" is the inconsistency window — it's typically milliseconds under normal conditions, but can stretch longer under network congestion or a partial outage.
Quorum-based reads and writes, briefly
Systems like Cassandra let you tune this trade-off explicitly per operation, rather than accepting a single fixed answer for the whole system: a write can require acknowledgment from just one replica (fast, but a very wide inconsistency window) or from a majority quorum of replicas (slower, but a much narrower window — and if read quorum + write quorum together exceed the total replica count, you mathematically guarantee every read sees the latest write, recovering strong consistency at the cost of the speed BASE was trying to buy you).
Vector clocks and conflict resolution, briefly
When two replicas each accept a write to the same key while partitioned from each other, reconciling them once the partition heals requires deciding which write "wins," or merging them. Some systems use a simple "last write wins" rule based on timestamps (simple, but can silently discard a legitimate concurrent write); others use more sophisticated structures like vector clocks to detect that two writes were genuinely concurrent (neither one "happened after" the other) and either resolve the conflict with custom application logic or surface both versions to the caller.
- A banking ledger — chooses consistency over availability during a partition. It's far better for a transfer to briefly fail than for two branches to disagree about whether ₹50,000 exists in an account.
- A social media "like" counter or view count — chooses availability over consistency. If two users briefly see slightly different like counts on the same post during a network hiccup, nobody is harmed, and refusing to show the count at all would be a much worse experience.
- DNS — a real-world, decades-old example of eventual consistency working at global scale: when a DNS record changes, different resolvers around the world catch up on their own schedule (bounded by TTL), and the whole internet doesn't grind to a halt waiting for every resolver to agree simultaneously.
- Amazon's shopping cart (the original motivating case for DynamoDB) — favored availability specifically because a customer being unable to add an item to their cart during a partition was judged worse for the business than occasionally needing to merge two slightly different versions of the same cart afterward.
- A distributed cache like Redis in cluster mode — typically favors availability and eventual consistency for cached data, on the reasoning that cached data is disposable and re-fetchable by definition, so briefly serving a stale cached value is an acceptable trade for staying up.
- Classify each type of data in your system by what actually breaks if it's briefly stale — a like count tolerates staleness fine; an account balance does not.
- Choose (or configure) a data store's consistency model per use case, rather than assuming one database technology's default is correct for every table or collection in your system.
- For systems offering tunable consistency (like Cassandra's per-query read/write quorum), be explicit about the choice in code, and document why a given operation needs strong versus eventual consistency.
- Design your application to tolerate the inconsistency window gracefully where it exists — for example, optimistic UI updates that assume a write succeeded, reconciling quietly if a later read disagrees.
- Don't chase strong consistency by default "to be safe" if the actual data doesn't need it — you pay for that safety in availability and latency, for no real benefit if brief staleness was always acceptable.
⚠️ Why this keeps happening
CAP is often taught as "pick any two of three," as if it were a permanent, all-the-time design decision — that's an oversimplification, and it leads people to apply the theorem far more broadly (and far more often) than the actual, narrower claim supports.
- Believing a system must give up partition tolerance entirely to get both consistency and availability. In practice, virtually every real distributed system has to tolerate partitions (networks fail); CAP is really about what happens specifically during one, not a permanent, all-the-time trade.
- Assuming "eventually consistent" means "consistency doesn't matter here." It means consistency is delayed, not abandoned — an application still has to handle the (usually brief) window where different replicas disagree, correctly.
- Treating every table or collection in a system as needing the same consistency model. A single application often has both strongly-consistent data (payments) and eventually-consistent data (view counts) living side by side, and conflating the two leads to either unnecessary latency or genuine correctness bugs.
- Assuming a NoSQL database is automatically "CAP-optimized" and never checking its actual, specific configuration. Most systems let you tune consistency per operation — leaving it at a default without understanding what that default actually guarantees is a common, quiet risk.
- Reaching for "last write wins" conflict resolution by default without considering whether it silently discards a legitimate concurrent write that the business logic actually needed to preserve or merge.
- Lower consistency requirements (fewer replicas required to acknowledge a write or read) generally mean lower latency and higher availability — measure this trade-off directly for your workload rather than assuming a fixed rule of thumb.
- For read-heavy, staleness-tolerant workloads, reading from the nearest or least-loaded replica (rather than always the primary) can meaningfully reduce latency, at the cost of occasionally serving slightly stale data.
- Watch the size of the inconsistency window under real production load, not just in a quiet test environment — network congestion and node failures widen it in ways a calm test setup won't reveal.
- For systems with tunable quorums, benchmark a few different read/write quorum combinations against your actual traffic pattern before locking one in — the right trade-off is workload-specific, not universal.
- Recognize that achieving strong consistency in a distributed system always costs something in latency or availability — there's no configuration that gets both for free; the question is always which cost your specific data can tolerate.
- Document, per data type, which consistency model it uses and why — a future engineer shouldn't have to reverse-engineer this from database configuration alone.
- Monitor actual replication lag/inconsistency window in production, and alert if it grows well beyond its normal baseline — a widening window is often an early signal of node or network trouble.
- Test your application's behavior during a simulated partition specifically (not just node failure) — the two produce meaningfully different failure modes, and a partition is what CAP is actually about.
- Build conflict-resolution logic (whichever strategy you choose) as a first-class, tested piece of the system, not an afterthought — it's the part that only really gets exercised during an actual partition, which makes it easy to leave undertested.
- Revisit consistency choices as a data type's usage changes — data that used to tolerate staleness fine (a view count) can, with a new feature built on top of it, suddenly need stronger guarantees than it originally had.
- Set up a small multi-node NoSQL cluster (or simulate one), write a value, then immediately read it from a different node before replication completes — observe the stale read.
- For a system with tunable quorums, configure a weak write quorum and a weak read quorum, and demonstrate a read that misses a very recent write; then reconfigure so read quorum + write quorum exceed the replica count, and confirm the same scenario now always returns the latest value.
- Simulate a network partition between two nodes each accepting writes to the same key, then reconnect them and observe how the system resolves the conflict (last-write-wins, or otherwise).
- Write a one-paragraph justification for which consistency model (strong vs. eventual) you'd choose for three different pieces of data: an inventory count during checkout, a "most recently viewed" list, and a password reset token.
✓ Quick recap
- CAP theorem: during a network partition, you can guarantee at most two of Consistency, Availability, and Partition tolerance — and partition tolerance is effectively mandatory for any real distributed system, so the real choice is C vs. A during a partition.
- BASE (Basically Available, Soft state, Eventual consistency) is the trade-off many NoSQL systems make in favor of availability.
- Eventual consistency means a write, once acknowledged, will reach every replica given enough time — but a read immediately after can briefly return a stale value.
- Systems with tunable quorums (like Cassandra) let you choose the consistency/availability trade-off per operation, rather than accepting one fixed answer for the whole system.
- Not all data in one application needs the same consistency model — classify data by what actually breaks if it's briefly stale, and choose accordingly.
Want a visual for this concept?
Generate a diagram tailored to “NoSQL Fundamentals — CAP, BASE & Eventual Consistency” — the AI picks whichever visual (flowchart, comparison, sequence, etc.) best fits.
Sign in to generate a visual →