NoSQL · Data models beyond tables
How do access patterns shape a NoSQL schema?
Short answer
Access patterns define the key, sort order, indexes and table layout. A NoSQL schema is correct only relative to the queries it must serve efficiently at the expected volume.
In a relational database you can add an index later and keep the schema. In many NoSQL systems the primary key is the layout, so a query that does not match it becomes a scan or requires a new index with its own write cost. That makes the query list a design input.
GET /users/:id -> pk USER#id
GET /users/:id/orders?limit=20 -> pk USER#id, sk begins_with ORDER#
GET /orders/:id -> pk ORDER#id
GET /orders?status=shipped -> GSI on status + created_at
GET /products/:id -> pk PRODUCT#idWhat to capture for each pattern
- The exact key values available from the request
- Filters, sort order and pagination requirements
- Peak reads and writes per second
- Whether stale data is acceptable
- The maximum number of items returned in one page
Patterns that cannot share a key need a secondary index or a duplicated table. That is not a failure; it is the cost of the query. The mistake is discovering an unsupported pattern after launch, when backfilling a new index or table is expensive.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1What do you do when a new query does not fit the primary key?
- 2How many access patterns are too many to support?
- 3How do you estimate the cost of a new index?
- 4Why can a filter on a non-key field be expensive?
Say it in the interview
I treat the access pattern list as the schema specification. For each query I capture the available key values, filters, sort order, volume and consistency tolerance, because those determine the primary key, sort key and indexes. A query that does not match the key becomes a scan or needs a secondary index, and both have a real cost. I revisit the list when features change, since a new filter can invalidate an otherwise sound design.
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.