The fastest way to fail a NoSQL modeling question is to sketch a normalized schema and then ask how you’d query it. That’s the relational reflex, and an interviewer watching for it will steer you into a wall on purpose. In DynamoDB, Cassandra, and MongoDB you list the read and write patterns first, then design tables that answer each one cheaply. Get that order wrong and every follow-up exposes it.
Most loops that touch NoSQL do it inside a broader system design round. You’ll get a prompt like “design a ride-tracking service” or “store and serve a user’s activity feed,” and somewhere in the middle the interviewer pins you down: what’s your partition key, how does that query hit disk, what happens when one user has ten million rows. Strong candidates treat the data model as a set of decisions with named tradeoffs. Weak ones reach for whatever they’d do in Postgres and hope nobody notices the missing join.
Access patterns come before columns
Before you name a single column, an interviewer wants to hear you enumerate access patterns. Not “users and orders” but the actual operations: get an order by id, list a customer’s orders newest-first, find every order in a warehouse placed today. Each one becomes a query you have to serve without scanning the whole table.
This is where DynamoDB’s single-table design comes from. You put multiple entity types in one table and shape the partition and sort keys so each access pattern maps to a single targeted query. A customer’s orders share a partition key like CUSTOMER#1234 and carry sort keys like ORDER#2026-01-15, so “list orders newest-first” is one query with a range condition and no scan. When the interviewer asks how you’d add “list orders by status,” you don’t bolt on a WHERE clause. You add a global secondary index keyed on status, because that’s a new access pattern and it needs its own index.
A follow-up you should expect: “your partition key is country, what breaks?” The answer is skew. A few countries hold most of the traffic, those partitions run hot, and DynamoDB throttles them while the rest sit idle. High-cardinality keys that spread reads and writes evenly are the whole game. As of late 2025 a DynamoDB GSI can use up to four attributes each for its partition and sort key, so you no longer hand-concatenate synthetic strings like STATUS#SHIPPED#DATE#2026, but the reasoning is identical: the key exists to serve a query and to spread load.
In Cassandra, the partition key decides your worst day
Cassandra looks similar on the surface and rewards the same query-first instinct, but the failure modes are sharper because a bad key degrades the whole cluster rather than inflating a bill. The partition key picks which node stores a row. The clustering key sorts rows inside that partition. Interviewers probe both.
The classic trap is the unbounded partition. Say you model a chat app with room_id as the partition key and message timestamp as the clustering key. Clean, until a busy room piles up months of messages in one partition, that partition crosses a few hundred megabytes, and reads and repairs on that node crawl. The size you want to quote is under 100MB per partition, ideally in the low tens. The fix the interviewer is fishing for is bucketing: make the partition key (room_id, day) or (room_id, month) so each partition stays bounded, then query the buckets you need.
Two more Cassandra answers worth having ready. ALLOW FILTERING is a warning sign, not a feature; if a query needs it, your model is wrong for that query and you should add a table or a materialized view built to serve it. And don’t reach for Cassandra as a queue. Deleting rows creates tombstones, reads have to scan past every tombstone to reach live data, and a queue table becomes a graveyard that gets slower as it drains. Naming that pitfall unprompted signals you’ve actually run Cassandra in production.
Embedding versus referencing is the MongoDB question
Mongo gives you documents and one modeling decision that comes up over and over: do you embed related data inside a document or store a reference and read it separately. Embedding makes reads fast because everything arrives in one fetch. References keep documents small and avoid duplication. The judgment call is about how the data is read and how it grows.
Embed when the child data is read with the parent and stays bounded: a blog post with its handful of tags, an order with its line items. Reference when the related set is large or unbounded, or shared across many parents. A user’s followers on a social app do not belong in the user document, because that array grows without limit and every write to the document rewrites the whole thing. The number to know is the 16MB document ceiling, and the anti-pattern is the ever-growing array marching toward it.
Interviewers also ask about the shard key, Mongo’s version of the same distribution problem. Pick one with high cardinality and even access, or you recreate the hot-partition issue you avoided in DynamoDB. A monotonically increasing key like a raw timestamp or a default ObjectId sends every new write to the same shard, so you either hash the key or combine it with something that spreads the load.
The primitives side by side
The three engines solve the same problem with different vocabulary. This is the mapping to keep straight when an interviewer switches databases mid-question.
| Engine | Unit that distributes data | How rows are ordered | The decision you have to defend | Anti-pattern to name first | Hard limit to cite |
|---|---|---|---|---|---|
| DynamoDB | Partition key (hashed) | Sort key within a partition | Which access patterns get their own GSI | Low-cardinality key creating a hot partition | ~10GB per partition-key value; single-digit-ms reads |
| Cassandra | Partition key mapped to a node | Clustering key within a partition | How you bound partition growth | Unbounded partition, ALLOW FILTERING, queue table | Keep partitions under 100MB, ideally under 10MB |
| MongoDB | Shard key | Index order on the collection | Embed the related data or reference it | Ever-growing array inside one document | 16MB per document |
Questions phrased the way they’re actually asked
The wording is rarely academic. It’s a concrete scenario with a trap folded in, and the interviewer is watching whether you spot the trap before they point at it.
- “You’re storing IoT sensor readings in Cassandra. What’s your partition key, and what stops one sensor’s partition from growing forever?”
- “In DynamoDB you have users and their orders. Model it as a single table and show me how you’d read a user’s five most recent orders.”
- “A product document in Mongo has a reviews array. At what point do you pull reviews into their own collection, and why?”
- “Your shard key is user_id and one power user generates most of the writes. What happens, and how do you fix it?”
Talking through it without sounding rehearsed
Start every NoSQL modeling answer the same way, out loud: let me list the access patterns first. Write them down. Then map each to a key design and say why it serves that query without a scan. When you introduce a partition or shard key, stress-test it against skew in the same breath, because the interviewer will ask anyway and beating them to it reads as experience. When you embed in Mongo, state the bound that makes embedding safe. When you bucket in Cassandra, state the growth you’re capping.
The people who land these rounds aren’t the ones who memorized that DynamoDB has GSIs and Cassandra has clustering keys. They’re the ones who can look at a proposed key and predict which query goes slow, which partition runs hot, and what they’d change. That prediction is the skill the round is measuring. Show it on the first key you name and the rest of the conversation gets much easier.
Keep sharpening your system design:
