Code10x
Document modellingeasy0-2 years

A `Customer` document embeds an `orders` array because "a customer has orders," and it reads beautifully for a month. What breaks as the data grows, and how would you redesign it?

The embed-versus-reference decision depends on whether the array is bounded, and an orders array on a customer is not — a customer who places one order a week for five years has hundreds of them, with no ceiling. As it grows, every read of the customer's profile pulls the whole order history along whether the page needs it or not, every new order rewrites the entire customer document, and the document creeps toward the size where growth gets expensive and, eventually, toward the hard 16 MB limit. The fix is to make orders its own collection with a customerId reference and an index on it, so reading a customer's profile touches one small document and reading their orders is a separate, paginated query — exactly the embed/reference table's rule: reference what's unbounded, embed what's bounded and read with its parent.

The lesson behind it →
PreviousA query for orders containing a line with SKU "A-1" and quantity over 5 uses `{ "lines.sku": "A-1", "lines.qty": { $gt: 5 } }` and returns an order where the SKU-A-1 line has quantity 1 and a completely different line has quantity 20. What went wrong, and what's the fix?Next A `Product` collection embeds a `List<String> tags` via Spring Data MongoDB's `@Document` mapping, and a service does `product.getTags().add("sale")` then relies on a later `repository.save(product)` to persist it. It works in a quick manual test but a code reviewer flags it as fragile. What's the actual risk, and how would you make the write explicit and safe?