Begin with the screen or operation
A document model should reflect how the application reads and changes data. An order detail page usually needs its line items together. A customer profile may need only a small subset of that customer's historical orders.
Those are different document boundaries.
A bounded embedded structure
{
"_id": "order-1001",
"customer_id": "customer-42",
"items": [
{"sku": "book-1", "quantity": 2, "unit_price_cents": 1800},
{"sku": "pen-2", "quantity": 1, "unit_price_cents": 400}
],
"shipping_address": {
"city": "Leeds",
"country": "GB"
}
}
Order items and the address at purchase time can be useful parts of the order document. An address snapshot should not silently change because the customer later updates their profile.
Know when references help
References can be useful for shared data, independently changing entities, and relationships that would make one document grow without a practical bound.
Storing every event for a long-lived customer in a single array creates a growth problem. A separate event collection with an appropriate index gives that history room to grow.
Think about updates
MongoDB operations are atomic at the single-document level. This makes a sensible document boundary valuable, but it does not mean every related record should be embedded.
When data is duplicated across documents, define how copies are refreshed and what inconsistency is acceptable. When several documents must change together, investigate transaction requirements and costs.
Validate with realistic shapes
Test with the largest expected order, the busiest customer, and the most frequent update. Average-sized examples can conceal the document growth and contention that matter in production.
The useful question is not whether embedding is better than references. It is which boundary makes this operation clear and sustainable.