Data model

Data modeling in system design ties entities to access paths: what you query, how often, and with which latency. Choose SQL versus NoSQL based on relationships, transaction needs, and query patterns — not hype.

Define primary keys, indexes for hot queries, denormalization for read-heavy feeds, and retention per table. Note ownership boundaries when services split — avoid shared mutable databases without a plan.

On interviews: sketch two to three core tables or document types, explain index choices, and state consistency expectations per entity.

Common pitfalls: normalized schema that requires ten joins for the main page; no plan for high-cardinality indexes; global secondary indexes without cost awareness.

Checklist:

• List core entities and relationships.
• Map entities to read/write access paths.
• Choose indexes for hot queries.
• State consistency and retention per store.