Embedding vs. Referencing

What we're doing: Apply both checklists to two different relationships from the same order document to show they can land on opposite sides.

// Order line items: read together, bounded (an order has a handful of items), owned only by this order
{ _id: 1, items: [ { sku: "X1", qty: 2 }, { sku: "X2", qty: 1 } ] }  // embed

// Customer record: shared across every order they've placed, has its own lifecycle
{ _id: 1, customerId: 987, items: [ ... ] }  // reference
{ _id: 987, name: "...", email: "..." }

2

All three embed signals point the same way here — this is the easy case.

6

Referencing wins because the customer record is shared across many orders and updated on its own schedule, independent of any one order.

Why this works: The same document can hold both an embedded and a referenced relationship, because the two checklists are evaluated per relationship, not once for the whole document.

What we're doing: Show why storing the parent id on the child, not an id array on the parent, is the referenced one-to-many default.

// Awkward: an ever-growing array of order ids on the customer document
{ _id: 1, orderIds: [101, 102, 103, /* ...thousands more over the account's life */] }

// Standard: the reference lives on the "many" side instead
{ _id: 101, customerId: 1 }   // order
{ _id: 102, customerId: 1 }   // order
db.orders.find({ customerId: 1 })  // finds all of a customer's orders via an index, no array growth on the customer

2

Putting the id array on the "one" side recreates the same unbounded-array problem referencing was meant to avoid.

6

Putting the reference on the "many" side and querying by it avoids growing any document, and an index on customerId makes the lookup fast.

Why this works: A one-to-many relationship has two documents that could hold the reference; putting it on the "many" side keeps every document's size independent of how many related records exist, which is the whole point of choosing to reference in the first place.

What we're doing: Match three different symptoms to the pattern that addresses each, showing the patterns are chosen by symptom, not by habit.

// Symptom: a product document embeds 500 reviews, most reads only need the newest 10
// -> subset pattern: embed the 10 most recent, reference the rest

// Symptom: every order-list page runs a $lookup just to show the customer's name
// -> extended reference pattern: copy { name } onto the order at write time

// Symptom: a dashboard recalculates a running total from thousands of documents on every read
// -> computed pattern: store the running total, update it incrementally on write

2

A large embedded array with a clear "usually only need the recent slice" access pattern is the subset pattern's signature symptom.

5

Extended reference trades a small amount of duplicated, rarely-changing data for eliminating a join on every read of a hot path.

8

Computed trades write-time work (updating the total) for read-time work (recalculating it) — worth it exactly when reads vastly outnumber writes.

Why this works: Naming the symptom first, then reaching for the matching pattern, keeps schema design grounded in an actual measured problem rather than applying a pattern because it sounds sophisticated.

What we're doing: Show a deliberate denormalization decision, including the explicit plan for keeping the copy in sync.

// Normalized (relational instinct): order only stores a reference
{ _id: 101, customerId: 1 }
// -> every order-list page needs a $lookup or a second query to show the customer's name

// Denormalized on purpose: a copy of the rarely-changing display name lives on the order
{ _id: 101, customerId: 1, customerName: "Joel M" }
// -> the order-list read needs no join; a rename updates existing orders only if that's a real requirement

2

The normalized version is correct by relational standards but costs a join on the single most common read (the order list).

6

The denormalized copy is a name, chosen because names change rarely — the decision explicitly accepts that a rename will not retroactively update past orders unless a migration does it.

Why this works: The word "denormalization" sounds like settling for something worse, but here it names a specific, bounded trade — a rarely-changing field, copied to remove a join from a hot read path, with an explicit answer for what happens if the source value changes.

What we're doing: Show the same two entities modeled two different, both-valid ways because the dominant access pattern differs.

// App A: mostly reads a blog post with its comments together, comments rarely queried alone
{ _id: 1, title: "...", comments: [ { user: "...", text: "..." } ] }  // embed

// App B: comments are heavily queried on their own (a "recent comments across the site" feed)
{ _id: 501, postId: 1, user: "...", text: "..." }  // reference, its own collection, indexed by postId

2

Embedding is the right call when the dominant read is "show a post with its comments" — one document, one read.

5

The same entities reference instead when a different access pattern (querying comments independently of any one post) dominates — embedding would make that pattern expensive or impossible to index well.

Why this works: Neither schema is "more correct" in the relational sense — both are valid document models of the same two entities. The deciding factor is which access pattern the application actually needs to serve cheaply, which is a performance question, not a normalization question.