NoSQL data models

Which NoSQL model fits which problem

Four families, each shaped around a different access pattern. Key-value (Redis, DynamoDB in its simplest use) does get and put by a single key, nothing else, at very low latency: caches, sessions, feature flags. Document (MongoDB, Couchbase) stores a JSON-ish object per key and can index and query fields inside it: application objects that vary in shape. Wide-column (Cassandra, Bigtable) spreads huge write volumes across a cluster and reads by row key plus a column range: time series, event logs. Graph (Neo4j) makes multi-hop relationship traversal cheap: social graphs, fraud rings, recommendations.

Pick by the questions you ask the data. If your only query is "give me the blob for this id," a key-value store beats a document store you would have to reason about.

Embedding vs referencing in a document store

The core modeling decision. Embed a child inside its parent when the child is bounded and you read it together with the parent: an order and its line items, a user and their address. Reference it (store an id and fetch separately) when the child is unbounded, large, or accessed on its own.

// Embed: read the whole order in one lookup
{ _id: "order#42", total: 90, items: [ { sku: "A", qty: 2 } ] }

// Reference: comments are unbounded and paged on their own
{ _id: "post#7", title: "..." }
{ _id: "comment#1", postId: "post#7", body: "..." }

wrong "embed everything, joins are slow in NoSQL." Embedding 50,000 comments makes every post read drag all of them along, and MongoDB caps a document at 16 MB. Unbounded arrays are the classic document-store bug.

Model for your access patterns, not your entities

In a relational database you model entities, normalize, then query however you like. NoSQL flips the order: list every read and write your app makes first, then design keys and documents so each one is a single cheap operation. This means denormalizing, storing the same fact in more than one place so a read needs no join. The cost lands on writes: when a user renames themselves, every document that copied their name is now stale until you fan the update out. You are trading write complexity and some duplicated storage for fast, predictable reads.

Eventual vs strong consistency, the version you need now

Many NoSQL stores replicate across nodes and let a read hit a replica that has not received the latest write yet, so you can read a value you just changed and see the old one. That is eventual consistency, and it is fine for a like count, wrong for an account balance. Most systems let you opt into a stronger read when a specific path needs it, at higher latency and cost. Know which of your reads can tolerate staleness before you reach for NoSQL, because you will be answering for it.

DynamoDB single-table design and item collections

Single-table design puts multiple entity types in one table and overloads the keys so related items share a partition key. Items with the same partition key form an item collection, and one Query returns the whole collection sorted by the sort key. That is how you fetch a user plus their orders plus their addresses in a single request instead of the N+1 round-trips DynamoDB would otherwise force, since it has no joins.

PK            SK              type      attrs
ORG#acme      ORG#acme        org       name=Acme
ORG#acme      USER#123        user      email=ada@x.com
ORG#acme      USER#123#ADDR   address   city=Berlin

Query(PK = "ORG#acme") returns the org and everything under it; adding SK begins_with "USER#" narrows to users. Generic attribute names (PK, SK, GSI1PK) let different entity types reuse the same physical keys, and a secondary index reindexes all of them at once. Sparse indexes fall out for free: only items that set GSI1PK land in that index.

How partition keys create or prevent hot partitions

The partition key is hashed to choose a physical partition, so it governs both correctness of your queries and how load spreads. You want high cardinality and even access. A key with three possible values (an order status, a country for a skewed user base) pins most traffic to a few partitions, and you throttle while total provisioned capacity sits mostly idle. Adaptive capacity reshuffles some heat but does not save a fundamentally low-cardinality key.

wrong "I have plenty of write capacity, so a sequential id like INVOICE#0001, INVOICE#0002 is fine." Monotonic keys concentrate every new write on the same partition. The fix is write-sharding: suffix the key with a bounded random or hashed digit (INVOICE#0001#3) and scatter-gather across the shards on read, or key by something already high-cardinality like a customer id.

GSI vs LSI: the consistency trap interviewers set

A Global Secondary Index lives on its own partitions, replicated asynchronously from the base table, so GSI reads are eventually consistent only. You cannot pass ConsistentRead: true to a GSI query; the API rejects it. A Local Secondary Index shares the base table's partitions and updates atomically with the item, so it can serve a strongly consistent read, but it must be defined at table creation. Base-table reads default to eventual and can request strong at roughly double the cost and higher latency. The read-your-write bug hides here: write an item, immediately query a GSI for it, get nothing, because propagation is usually sub-second but bounded by no SLA.

When NoSQL is the wrong tool, and what interviewers grade

NoSQL earns its keep when access patterns are known and stable, scale is horizontal, and you can live with denormalized writes. It fights you when you need ad-hoc queries the model was not shaped for, multi-entity transactions, or a schema still in flux, since changing your access patterns can mean a data migration rather than a new index. Treat BASE against ACID as a spectrum: Dynamo-style stores let you tune it, and a quorum where read plus write replicas exceed the replica count (R + W > N) buys strong consistency per operation at the price of latency. Interviewers grade whether you name your access patterns before touching keys, reach for embedding versus referencing by reflex, and volunteer the GSI eventual-consistency limit before they corner you with it.