How do you approach data modelling in DynamoDB, and how is it different from relational design?

Summary

Start from the access patterns, not the entities: list every query the application needs (with filters, sort order and volume), then design keys and indexes so each pattern is a single GetItem or Query. Denormalise and duplicate data where needed, since there are no joins.

Longer Answer

Relational design normalises first and lets SQL answer any question later. DynamoDB inverts that: flexibility is traded for predictable performance. Steps:

1. Write down entities and relationships, then the access patterns ("get orders for a customer, newest first", "get order by ID", "list open orders by warehouse").
2. Choose primary key formats so related items share a partition key and sort correctly.
3. Add GSIs for patterns the primary key cannot serve.
4. Decide where to duplicate attributes and how to keep copies consistent (transactions or streams).

A new access pattern later may need a new GSI or a backfill, so collect patterns carefully up front.

Key Points

• Access patterns first.
• Each pattern = one GetItem/Query.
• Denormalise; no joins.
• New patterns may need GSIs and backfills.

What interviewers look for

Starting from access patterns. Candidates who model tables like SQL and then 'add a GSI for everything' have not used DynamoDB at scale.

Follow-up questions

• What happens when a new access pattern appears after launch?