Model what you store
The data model names the core entities, their fields, and how they relate. Picking it well shapes everything downstream, because storage choices follow from how data is shaped and accessed.
Steps to a model
- List entities like user, post, and comment.
- Define fields and the identifier for each.
- Map relationships such as one user has many posts.
- Note access patterns like read a feed or look up by id.
Let access drive storage
- Relational suits rich queries, joins, and transactions.
- Key value suits simple lookups at massive scale.
- Document suits flexible nested records.
- Wide column suits heavy write and time series loads.
Denormalize on purpose
At scale you may copy data so a read needs one lookup instead of a join. State that this trades write complexity and consistency for read speed, and that the choice follows the dominant access pattern.
Key idea
Define entities, relationships, and access patterns first, then choose storage that fits those patterns rather than forcing patterns onto a default database.