NoSQL — document (MongoDB), key-value (Redis), column (Cassandra), graph (Neo4j): Question bank

First: the words this page keeps using

Before you can spot the traps, a few ideas must be nailed down on this page — not left to memory of an earlier note.

The picture behind the quorum symbols

Everything in the quorum sections uses three letters. Meet them on the picture below.

Formula Why

$W + R > N$ forces the sets to share a node Imagine $N$ numbered boxes (the replicas). A write drops its new value into some $W$ of them. Later a read opens some $R$ of them. Step 1 — WHAT: suppose, to get a contradiction, the read set and write set share no box. Step 2 — WHY: if they never overlap, the write's $W$ boxes and the read's $R$ boxes are all different boxes, so together they use $W + R$ distinct boxes. Step 3 — but there are only $N$ boxes in total, so $W + R \leq N$ . Step 4 — WHAT: this directly contradicts our chosen rule $W + R > N$ . WHY it matters: a contradiction means the "no shared box" assumption was impossible, so the read and write sets must overlap in at least $W + R - N \geq 1$ box. That shared box was one of the $W$ that received the write, and the read's version-stamp comparison (defined just above) then picks its value as the newest — guaranteeing the read sees the latest write.

True or false — justify

TF: "NoSQL" means these databases forbid the SQL language.

False — it stands for "Not Only SQL". Some (like Cassandra's CQL) even look like SQL; the point is they aren't the relational rows-and-joins model, not that they ban a syntax.

TF: A MongoDB collection forces every document to have the same fields.

False — schema is per-document, so one product can have author and another size. But the shape still exists in your app code (see the schema definition above), it just isn't enforced by the DB.

TF: Redis can safely serve a dataset larger than available RAM at full speed.

False — Redis keeps its data in memory, so the boundary condition is strict: once the dataset exceeds RAM you hit eviction or OS swapping, which destroys the microsecond latency you chose Redis for. True only if the dataset fits in RAM.

TF: Cassandra lets you add any WHERE filter you like after the table exists.

False — you can only query efficiently on the partition/clustering keys you designed for. Ad-hoc filters need a full scan or a secondary index and defeat the purpose.

TF: A graph database like Neo4j makes bulk aggregations (sum all sales) faster than SQL.

False — graphs win on deep relationship traversal (index-free adjacency), not on scanning-and-summing millions of rows, where a relational or column store is better.

TF: With

W + R > N

you are guaranteed to read the latest write.

True — by the overlap argument in figure s02, the read set and write set share at least

W + R - N \geq 1

replica, and its version/timestamp then selects the newest value. See Sharding and Replication.

TF: Choosing CP means your CP system is always consistent and never rejects requests.

Half-true — it favours Consistency during a partition by refusing/erroring on the isolated side; when the network is healthy it happily serves both C and A.

TF: Denormalising (duplicating) data in a document store is a design smell to avoid.

False here — in document stores duplication is a deliberate tradeoff buying single-read locality; the cost is harder updates, not bad design.

TF: An LSM write path (append to a log + memtable, merge later — see the LSM definition above) makes Cassandra writes slow because it must sort before storing.

False — writes append to a commit log and an in-memory memtable (fast, no in-place seek); sorting/merging happens later during background flush/compaction. See figure s03 and Database Indexing (B-tree, LSM).

TF: Eventual consistency means the database may permanently lose or corrupt data.

False — it's a temporary replica divergence that converges once messages flow; it's a latency-vs-freshness tradeoff, not corruption.

Spot the error

Error: "I'll use Redis as my primary catalog store and run SCAN to filter products by price each request."

SCAN walks every key — that's an

O (N)

pass with no query engine. Key-value is for fetch-by-known-key; product filtering belongs in a document or relational store.

Error: "I chose

N = 3, W = 1, R = 1

because

1 + 1 = 2

and I want strong consistency."

W + R = 2 \neq > 3 = N

, so read and write sets may not overlap — this is eventual consistency. Strong needs e.g.

W = 2, R = 2

Error: "My CAP plan: drop Partition-tolerance (P), keep Consistency and Availability."

In a distributed system partitions will happen (cut cables, GC pauses), so P is not optional — as the CAP definition and figure s04 show, the real choice is CP vs AP when a partition occurs.

Error: "MongoDB has no schema so I skipped all data modelling."

The schema moved into your application and your query/index choices, not away. Unindexed nested queries still cost an

O (N)

collection scan.

Error: "Neo4j scales like Cassandra, so I'll shard my 1-billion-node graph across 50 machines easily."

Graphs are hard to shard because a traversal may hop across arbitrary partitions, breaking index-free adjacency; horizontal scaling is exactly graph DBs' weak point.

Error: "Friends-of-friends in SQL is fine — I'll just add one more self-join per hop."

Each hop is another self-join whose cost multiplies with depth; a 5-hop query can explode combinatorially, which is precisely why graph traversal engines exist.

Error: "I set a Redis key with no EX, expecting the cache entry to expire like the others."

Without a TTL the key lives forever, silently filling RAM. Cache entries need an explicit expiry or eviction policy — see Caching Strategies.

Why questions

Why does a single document read often beat a SQL join for fetching one entity?

The nested object (post + comments) lives together on disk, so it's one read with no join lookups — locality wins when the access pattern is "give me this whole thing".

Why does Cassandra hash the partition key instead of storing rows in insertion order?

Hashing spreads rows evenly across nodes so writes don't hotspot one machine, enabling masterless linear scaling (see figure s03). See Hashing and Hash Maps.

Why is

O (1)

key-value lookup possible without an index scan?

The key is hashed straight to its bucket/slot, so on average you jump to the value in constant time instead of searching. See Hashing and Hash Maps.

Why does BASE trade consistency for availability rather than the reverse?

BASE systems (AP) prioritise always answering during partitions, accepting brief replica disagreement that converges later — the opposite priority from ACID's strict correctness.

Why must you design a Cassandra table around the query, not the entity?

There are no joins and no cheap ad-hoc filters, so the partition/clustering keys must already match how you'll read — the query shape is baked into the storage layout.

Why is index-free adjacency the key idea in graph databases?

Each node stores direct pointers to its neighbours, so one hop is

O (1)

regardless of total graph size — no global index lookup per relationship.

Edge cases

Edge: What happens to a MongoDB query on a nested field with no index?

It falls back to an

O (N)

full collection scan — schema flexibility doesn't remove the need for an index on hot query paths.

Edge: With

N = 3

, you pick

W = 3, R = 1

. Consistent? What's the downside?

3 + 1 = 4 > 3

so reads are strongly consistent, but writes must ack on all replicas, so a single slow/down node blocks every write (low write availability).

Edge: A Redis counter INCR page:views under concurrent clients — is it safe?

Yes — Redis commands are atomic single-threaded operations, so INCR never loses an increment even with many concurrent callers.

Edge: During a network partition in an AP store, two clients write different values to the two sides — what then?

Both writes succeed locally; on reconnection a conflict-resolution rule (last-write-wins by version/timestamp, or version vectors) reconciles them, so temporary divergence resolves without an error.

Edge: You have zero relationships to traverse (single flat lookup) — is Neo4j the right pick?

No — with no traversal, graph overhead buys nothing; a key-value or document store is simpler and faster for a plain by-key fetch.

Edge: What is the minimum

W + R

that still gives strong consistency for any

N

Any pair with

W + R = N + 1

, the smallest overlap of exactly one shared node (e.g.

N = 5

needs

W + R = 6

). Below that you get eventual consistency.

Recall Quick self-check

$N$ , $W$ , $R$ stand for ::: total replicas, write-quorum size, and read-quorum size respectively. C, A, P in CAP stand for ::: Consistency (every read sees the latest write), Availability (every request gets a non-error answer), and Partition tolerance (works when the network splits nodes into groups that can't talk). Why P is not optional, so the real choice is CP vs AP ::: real networks always partition eventually (cut cables, GC pauses), so you can't discard P; you decide whether to favour C or A during a partition. What LSM (Log-Structured Merge) does differently from a B-tree ::: LSM appends writes to a log and in-RAM memtable and merges later; a B-tree seeks to the exact spot and overwrites in place, so LSM absorbs high write rates. A version/timestamp is ::: a stamp on each write that lets a read compare several copies and keep the newest — the tie-breaker that makes a quorum overlap useful. Why $W + R > N$ guarantees a fresh read ::: two sets of boxes summing above $N$ can't fit in $N$ distinct boxes, so they must share ≥1 box holding the newest value. The real NoSQL skill ::: matching the data model to the access pattern, not memorising which product is "best".