Data Modeling
What this domain tests
The Data Modeling domain tests whether you can turn business requirements and query access patterns into a document model. Expect questions on cardinality, embedding versus referencing, atomicity, document growth, and the 16 MB BSON document limit. The exam favors models driven by how the application reads and writes data, not by relational normalization.
Core rules
- Model for the application's access patterns: data read together is usually stored together.
- Embed when the child data is bounded, owned by the parent, and updated with it.
- Reference when data is unbounded, shared across many parents, or updated independently.
- Avoid unbounded arrays; a document that grows forever eventually hits the 16 MB limit and causes write amplification.
- Duplication is acceptable when it removes frequent joins, but you must own the update path.
- Plan atomicity: a single-document write is atomic; multi-document transactions are available but have cost and limits.
Worked example
An order has 1–20 line items, and the application displays the order and its items together. Model one orders document with an embedded items array. The array is bounded, items are owned by the order, and reading the order needs no second query. Keep a snapshot of product name and price inside each item so historical orders do not change when the catalog changes. Reference customerId instead of embedding the full customer because customer data is shared across orders and updated independently.
Traps
Normalizing every entity into separate collections; embedding an unbounded activity log; putting the same array on both sides of a many-to-many relationship; ignoring update frequency; and forgetting that a document has a hard size ceiling.