NoSQL · Data models beyond tables
How do you approach data modeling in NoSQL?
Short answer
Start from the queries, then design keys and documents so each query is a bounded, single-partition read or write. Model aggregates and duplicate data where needed instead of normalising first.
Relational modelling usually starts with entities and normalises to remove duplication. NoSQL modelling starts with access patterns: which screen or API call reads which fields, at what volume, with what ordering and consistency. The schema is the physical plan for those operations.
A workable process
- List every read and write with its key, filters, sort order and expected volume
- Group fields that are read and written together into an aggregate
- Choose a partition key with high cardinality and even access
- Add a sort key or clustering column to support ranges and ordering
- Identify queries the primary key cannot serve and plan an index or a second table
- Check the largest partition and document size before committing
{
"pk": "USER#7",
"sk": "PROFILE",
"name": "Asha",
"plan": "pro"
}
{
"pk": "USER#7",
"sk": "ORDER#2026-10-01#1042",
"total": 1798,
"status": "shipped"
}Write down the cost of each pattern. A query that fans out to many partitions is not automatically wrong, but it must be a deliberate decision with a latency and throughput budget, not an accident discovered in production.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1How do you handle a query that was not in the original access patterns?
- 2What makes a good partition key?
- 3When do you use a single-table design?
- 4How do you estimate partition size?
Say it in the interview
I start with the queries rather than the entities. For each read and write I capture the key, filters, ordering, volume and consistency need, then group fields that are used together into an aggregate. The partition key needs high cardinality and even access, and the sort key supports the ranges I actually query. I also check the largest partition and document size. It is an iterative process, because a NoSQL schema is much harder to change once production data exists.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live NoSQL mock interview and get scored feedback on depth, clarity and confidence.