Data model

Data model

The data model turns the API into entities, relationships and keys, then picks a store by how the data is read and written. In an interview, list the entities the endpoints touch, mark the one-to-many and many-to-many links, write down the hot queries, choose a relational or key-based store to fit them, and name the key or index each query uses — including which field would be the partition key once one machine isn't enough. Copy data into the shape of the hottest read when assembling it on every request would be too slow.

Use when

Right after the API — each endpoint's reads and writes become the list of access patterns · Choosing between a relational database and a key-based store · Naming the partition key before the scale deep dive

Avoid when

Drawing a full entity diagram with every column — the interview needs entities, keys and hot queries · Picking a database brand before listing the access patterns

Trade-offs

Relational gives flexible queries, joins and transactions, and scales writes only with sharding work · Key-based stores give fast, predictable reads for the queries their keys were built for, and are rigid for new ones · Copying data speeds the hot read and costs a write for every copy · Each index speeds a read and taxes every write

Requires

API design