NoSQL Datastores Interview Questions
Reviewed by Mark Dickie · Last updated
5 questions on this page you can answer and see marked on the spot. Go to the first one
NoSQL datastores are non-relational databases designed for flexible schemas, horizontal scaling, and high throughput across distributed nodes. For an interview on this topic, you should know the four major families (document, key-value, column-family, graph), the CAP theorem and how each datastore trades off consistency vs availability under partition, and the patterns for sharding and replication that let these systems scale out. Expect questions on read/write consistency levels, eventual consistency vs strong consistency, and concrete trade-offs between systems like MongoDB, Cassandra, DynamoDB, Redis, and Neo4j.
What are the main NoSQL datastore families?
| Family | Example systems | Data model | Typical use case |
|---|---|---|---|
| Document | MongoDB, CouchDB | JSON/BSON documents with nested fields | Content management, catalogs, user profiles |
| Key-value | Redis, DynamoDB, Memcached | Flat key mapped to a value (blob, counter, set) | Caching, session stores, lookups by ID |
| Column-family | Cassandra, HBase, ScyllaDB | Partitioned rows of sparse, wide column families | Time-series, event logging, write-heavy analytics |
| Graph | Neo4j, Amazon Neptune, ArangoDB | Nodes and edges with typed relationships | Recommendation engines, fraud detection, social graphs |
How does the CAP theorem apply to NoSQL systems?
The CAP theorem says a distributed datastore can guarantee at most two of three properties at once: consistency (every read sees the latest write), availability (every request gets a response), and partition tolerance (the system keeps running despite network splits). Because partitions are unavoidable in real networks, the practical choice is between CP (consistency + partition tolerance) and AP (availability + partition tolerance).
- CP systems (e.g., HBase, MongoDB with majority write concern) reject or block requests during a partition rather than serve stale data.
- AP systems (e.g., Cassandra with eventual consistency, DynamoDB) keep serving reads and writes during a partition and reconcile replicas afterward.
- Tunable consistency lets you choose per query: Cassandra offers levels such as
ONE,QUORUMandALL, while DynamoDB offers a per-read choice between eventually consistent and strongly consistent reads. - Eventual consistency means replicas converge over time, not immediately; understanding how read-repair, anti-entropy, and hinted handoff work is a common interview topic.
When should you choose NoSQL over a relational database?
Pick NoSQL when your workload needs horizontal scale, your schema evolves fast, or your access pattern is keyed lookups rather than ad-hoc joins. Relational databases remain the better fit when you need multi-record ACID transactions, complex joins across many tables, or strict schema enforcement at write time. Interviewers often push you to justify a choice with specifics: expected write volume, query latency targets, data shape, and operational cost.
Key facts
- Tarmac has 173 NoSQL Datastores interview questions on this topic, 10 of them on this page, at difficulty 1–5 of 5.
- Tarmac tracked 437 job postings asking for NoSQL Datastores in September 2026.
- Roles asking for NoSQL Datastores advertise a median base salary of £97,500, across 24 job postings as of September 2026.
- Tarmac last reviewed these NoSQL Datastores interview questions on 20 October 2026.
At a glance
| Questions | 10 shown · 173 in the bank |
|---|---|
| Difficulty | 1–5 of 5 |
| Formats | True / false, Multiple choice, Ordering, Fill in the blank, Short answer, Code output, Flashcard, Multiple answer, Find the bug |
What you'll review
- tunable consistency
- partition clustering keys
- wide column model
- dynamo capacity modes
Practice questions
Try one before you open the answer. Pick an option and press Check; it's marked on the spot.
In Apache Cassandra, the consistency level (e.g., ONE, QUORUM, ALL) is specified on a per-operation basis — each individual read or write can choose its own consistency level — rather than being a fixed cluster-wide configuration.#
Options
Show answer
True. Cassandra lets each read or write specify its own consistency level, so ONE, QUORUM, and ALL can be mixed freely against the same data. The consistency level is a per-operation parameter supplied by the client, not a fixed property of the cluster, keyspace, or table.
Cassandra's tunable consistency model lets the client pass a consistency level with each read or write request, so two operations against the same table can use different consistency levels. This is what 'tunable' means: the trade-off between latency/availability and consistency is decided per-operation, not hard-wired into the schema or replication settings.
In Apache Cassandra, a write request with consistency level ALL must receive acknowledgment from every live replica for that partition's replication factor before the write is acknowledged as successful to the client.#
Options
Show answer
True. With consistency level ALL, the coordinator waits for every replica of the partition (all N replicas set by the replication factor) to acknowledge the write before returning success. If any replica is unavailable, the write fails at that consistency level, unlike QUORUM or ONE which require only a subset of acknowledgments.
Consistency level ALL means the coordinator waits for acknowledgments from all replicas that store the relevant partition (i.e., all N replicas determined by the keyspace's replication factor). If any replica fails to acknowledge, the write does not succeed at consistency level ALL. This contrasts with QUORUM (a majority of replicas) or ONE (any single replica).
In Cassandra's data model, what does the partition key portion of a primary key determine?#
Options
Show answer
The partition key determines which node(s) store the partition's data. Cassandra hashes the partition key to compute a token that maps onto the ring, co-locating all rows with the same partition key. Clustering columns, by contrast, control row ordering within a partition, not data placement.
Cassandra applies a hash function to the partition key to produce a token; that token maps the partition to one (or, with vnodes, a small set) of nodes in the ring. All rows sharing the same partition key are stored together on that node. Clustering columns, not the partition key, control row ordering within a partition; consistency level is a query-level setting, and data types are independent of key role.
In Cassandra's wide-column data model, order these storage hierarchy levels from the broadest container to the most specific data unit.#
Put these in order
Show answer
The correct order from broadest to narrowest is: Keyspace → Table (column family) → Partition → Row. A keyspace is the top-level container defining replication; a table groups related partitions; a partition is the set of rows sharing a partition key on one node; a row is a single sorted entry within a partition identified by clustering columns.
Cassandra organizes data in a strict containment hierarchy: a keyspace is the outermost container that also defines replication strategy; within it, tables (historically called column families) group partitions that share a schema; each partition is the set of rows that share a partition-key value and physically reside on a single node (and its replicas); within a partition, individual rows are sorted and identified by clustering columns. This nesting — keyspace → table → partition → row — is the foundational structure of the wide-column model, and each level strictly contains the next.
In Amazon DynamoDB, the _________ capacity mode requires you to specify the exact number of Read Capacity Units (RCU) and Write Capacity Units (WCU) your table can consume per second, whereas the _________ capacity mode automatically scales throughput to match actual traffic and bills you per request instead of per reserved unit.#
Show answer
In Amazon DynamoDB, the provisioned capacity mode requires you to specify the exact number of Read Capacity Units (RCU) and Write Capacity Units (WCU) your table can consume per second, whereas the on-demand capacity mode automatically scales throughput to match actual traffic and bills you per request instead of per reserved unit.
DynamoDB offers two capacity modes. The provisioned mode lets you set RCU and WCU values (with optional auto-scaling) and is cost-effective for predictable workloads. The on-demand mode instantly accommodates any traffic spikes and charges per million read/write request units, removing the need to pre-provision capacity.
In Cassandra's tunable consistency model, what inequality involving the number of replicas acknowledged on reads (R), the number acknowledged on writes (W), and the replication factor (RF) must be satisfied to guarantee strong (linearizable) consistency?#
Show answer
R + W > RF — the sum of replicas acknowledged for reads and writes must exceed the replication factor.
Strong consistency in Cassandra is guaranteed when the read and write consistency levels overlap: if R + W > RF, then at least one replica that acknowledged the write is guaranteed to be included in the read set, so the reader observes the latest value. This is the foundational condition of Cassandra's tunable consistency model.
The following Python code simulates a Cassandra wide-column table defined as:#
partition = {}
def insert(user_id, event_time, event_type):
if user_id not in partition:
partition[user_id] = {}
partition[user_id][event_time] = event_type
def query_partition(user_id):
if user_id not in partition:
return []
return [(t, partition[user_id][t]) for t in sorted(partition[user_id])]
insert("alice", 3, "login")
insert("alice", 1, "signup")
insert("alice", 2, "view")
insert("alice", 5, "logout")
insert("alice", 4, "click")
result = query_partition("alice")
for event_time, event_type in result:
print(f"{event_time}:{event_type}")Show answer
1:signup
2:view
3:login
4:click
5:logout
The five inserts all share partition key "alice", so they land in the same partition. Within that partition the clustering key event_time determines on-disk ordering — Cassandra stores and returns rows sorted by the clustering column ascending by default, regardless of insertion order. The sorted() call in query_partition mirrors this: it yields the timestamps 1, 2, 3, 4, 5 with their respective event types, producing 1:signup, 2:view, 3:login, 4:click, 5:logout.
What are the key trade-offs in Cassandra between using consistency level ONE versus QUORUM for both reads and writes, in terms of availability, latency, and consistency guarantees?#
Show answer
With CL = ONE, the coordinator contacts only the fastest responsive replica for the partition, minimizing latency and maximizing availability — the operation succeeds as long as any single replica is reachable, tolerating up to N-1 replica failures for a replication factor N. However, it provides only eventual consistency: a read may return a stale value if the contacted replica has not yet received the most recent write (e.g., during a hinted handoff or replication lag window). With CL = QUORUM, the coordinator must receive responses from a majority of replicas (⌈N/2⌉ + 1, i.e., 2 of 3 for RF=3), which tolerates up to ⌊N/2⌋ replica failures. Paired with QUORUM writes, it delivers strong consistency via the R + W > N overlap rule. The trade-off is higher per-operation latency (waiting for a majority, not the fastest single response) and reduced availability: if a majority of replicas are unreachable, the operation fails. The consistency level is chosen per-statement, so a workload can use QUORUM for critical reads/writes and ONE for best-effort or latency-sensitive operations.
These three flashcards cover the core of Cassandra's tunable consistency model at senior depth: (1) the R + W > N overlap rule that underpins strong consistency without LWT, (2) the SERIAL/LOCAL_SERIAL layer that Lightweight Transactions add on top of the normal tunable CL, and (3) the concrete availability/latency/consistency trade-off between CL=ONE and CL=QUORUM including failure tolerance math.
Consider the following statements about the partition key and clustering key in Apache Cassandra's data model. Which of these statements are true?#
Options
Pick every one that applies.
Show answer
The true statements are: range filters on clustering columns within a partition are natively supported without ALLOW FILTERING; rows within a partition are physically sorted by the clustering key columns; and the partition key is hashed (Murmur3 by default) to determine node placement. Range filters on partition keys are not natively supported because hashes are unordered, and the partition key may be composite while clustering keys are optional.
a is true: within a partition, clustering columns are stored in sorted order, so equality and range predicates on them are natively served without ALLOW FILTERING. c is true: that sorted storage is a fundamental on-disk property of each partition in Cassandra's SSTable layout. d is true: the partitioner (Murmur3Partitioner by default) hashes the partition key to a token that maps to a node via the cluster's token ring. b is false: partition keys are hashed, not sorted, so range scans across partition key values are not natively supported — they force a full-table scan with ALLOW FILTERING and return arbitrary, not sorted, order. e is false: the partition key can be composite (multiple columns grouped inside the outer parentheses), and a table may declare zero clustering columns if only point lookups by partition key are needed.
A team is building a page-view tracking system in Cassandra. They want to track total views per page per day using a counter, while also storing the page's URL for display purposes. The following CQL table definition fails to execute. Identify the buggy line.#
CREATE TABLE daily_page_views (
page_id text,
view_date date,
total_views counter,
page_url text,
PRIMARY KEY (page_id, view_date)
);Show answer
The bug is on line 5.
Cassandra enforces a strict rule: a table that contains a counter column may only contain counter columns (for data) and primary key columns. It cannot contain regular (non-counter, non-primary-key) columns such as page_url text on line 5. The page_id and view_date columns are part of the primary key, so they are exempt from this restriction, but page_url is a regular column declared in a table that also declares total_views counter — a combination CQL rejects at table-creation time. The fix is to move page_url (and any other descriptive attributes) into a separate non-counter table keyed by page_id, keeping the counter table dedicated to increments only.
Related interview questions
Job market
See nosql-datastores salaries and hiring demand from live job postings.
The other 163 questions
This page shows 10 and marks what you pick. That's as far as a page can go. A free account opens the other 163 and keeps every answer. What you miss comes back until it's right: after a day, then at longer gaps.
Free · the whole bank · 100 marked answers per 30 days · written feedback on the paid plan