INTRO
MongoDB flexibility is a trap: you can embed everything until a single `orders` document hits 16MB. I start from access patterns - how the app reads and writes in one request - and let that drive embed vs reference.
Embed what you always read together
If the UI always shows line items with the order header, embedding `lines` can save round trips. Cap growth: if lines can number in the thousands, normalize to `order_lines` with `orderId`.
Denormalize a few display fields (product name snapshot) when the catalog can change but historical views should stay stable.
Audit fields and soft deletes
Operational apps need `createdAt`, `updatedAt`, and often `createdBy`. Soft deletes (`deletedAt`) simplify “undo” but complicate unique constraints - plan partial unique indexes if your driver supports them.
Heavy audit trails belong in append-only collections or external log stores if query volume is high.
KEY TAKEAWAYS
“Model for query patterns, not for diagram aesthetics.”
- 02
Embed small, bounded children; reference large or shared data.
- 03
Index exactly what you filter and sort in list screens.
- 04
Plan audit and soft-delete early - they affect constraints and size.
CONCLUSION
Closing thought
Mongo works best when documents match real screen loads. Fight the urge to nest everything; reference when data is shared or unbounded. Ready to talk scope? Use Contact — or browse Services for fit.
CONTINUE
Related pages
UP NEXT
Express Middleware Patterns That Scale
How I order middleware, share request context, and centralize errors so new routes do not reinvent security checks.
Read next article