Data Modeling

What we're doing: Show the same two entities (a blog post and its comments) modeled two different ways for two different workloads.

// Workload A: readers view a post with all its comments together, comments rarely edited alone
{ _id: 1, title: "...", comments: [ { user: "a", text: "..." }, { user: "b", text: "..." } ] }

// Workload B: comments are moderated independently, searched across posts, and can be very numerous
{ _id: 501, postId: 1, user: "a", text: "..." }
{ _id: 502, postId: 1, user: "b", text: "..." }

2

Workload A embeds comments because they are always read with the post — one query gets everything.

5

Workload B references comments in their own collection because they are queried and moderated independently of any one post.

Why this works: Neither shape is "more correct" in the abstract — a relational-thinking reviewer might flag the embedded version as denormalized, but it is the right choice if workload A is real. The schema is a means to a performance end, not a modeling exercise judged on its own terms.

What we're doing: Show two access patterns on the same two entities leading to a schema an entity-only design would not have picked.

// Access patterns:
// - Every page load: "get this order with its line items" (very frequent)
// - Monthly job: "sum revenue per product across all orders" (rare, can be slow)

db.orders.insertOne({ _id: 1, customer: "a", items: [ { sku: "X1", qty: 2, price: 9.99 } ] })
// items embedded — pattern 1 needs them together, pattern 2 can afford a slower aggregation scan

1

Listing patterns with frequency first makes the tradeoff explicit before any document shape is chosen.

5

Items are embedded because the frequent pattern needs them with the order; the rare pattern can absorb the cost of scanning embedded arrays.

Why this works: If the monthly revenue job were instead run every few seconds for a live dashboard, the same entities would likely justify a separate, indexed line-items collection instead — the entities did not change, the access pattern did.

What we're doing: Show a single feature area (e-commerce orders) exhibiting three different workload types across three of its access patterns.

// Same "orders" data area, three different workload types:

// 1. Placing an order: write-heavy + transactional (deduct inventory, create order, atomically)
db.orders.insertOne({ ... })  // inside a multi-document transaction with an inventory update

// 2. Customer's order history: read-heavy
db.orders.find({ customerId }).sort({ createdAt: -1 })  // frequent, wants speed over write cost

// 3. Daily revenue report: time-series-shaped, read pattern is aggregation-over-time
db.orders.aggregate([ { $match: { createdAt: { $gte: startOfDay } } }, { $group: { _id: null, total: { $sum: "$amount" } } } ])

2

Placing an order needs atomicity across two pieces of data — a transactional workload.

4

Reading order history is frequent and read-dominant — a read-heavy workload, worth denormalizing for.

6

The revenue report is naturally time-ordered and aggregated — a time-series-shaped access pattern even though "orders" is not usually called a time-series collection.

Why this works: The same collection can serve access patterns of different workload types — recognizing that per-pattern, rather than trying to label the whole collection one type, is what keeps the schema decision grounded in the actual queries.

What we're doing: Show the principle applied to fields that are not conceptually the same entity, but are always read together.

// "userId", "layout", and "lastViewedFilters" are not the same conceptual entity —
// but a dashboard render always needs all three together, every time.
db.dashboards.insertOne({ userId: u, layout: { widgets: [...] }, lastViewedFilters: { range: "7d" } })

db.dashboards.findOne({ userId: u })  // one read gets everything the page needs

1

The justification for co-locating these fields is access frequency, not conceptual sameness — this is the principle applied directly, independent of any embed-vs-reference relationship question.

4

One read services the whole page render — the payoff the principle is built around.

Why this works: This is worth calling out separately from "embed vs. reference," because that framing usually implies two related entities — the co-location principle applies even to fields with no obvious "relationship" at all, purely because they are read together.

What we're doing: Show the same "movie has a user" relationship modeled two ways depending on which access pattern dominates.

// If the app shows a lightweight review snapshot beside a movie (name, not full profile):
db.movies.insertOne({ title: "...", review: { name: "Joel M", rating: 5 } })

// If the app also needs the same user's full, frequently-updated profile elsewhere,
// and that profile is shared across many movies the user reviewed:
db.movies.insertOne({ title: "...", userId: 987 })
db.users.insertOne({ _id: 987, name: "Joel M", email: "...", bio: "..." })

2

A small, rarely-changing snapshot embedded directly avoids a $lookup for the common "show the review" read.

6

The full user profile is referenced because it is shared across every movie the user reviewed, and updating a bio should not mean rewriting every movie document that mentions them.

Why this works: Both are "the same relationship" (movie-to-user) modeled differently because the actual questions — how often read together, how often updated independently, how widely shared — have different answers for a review snapshot versus a full profile.

What we're doing: Show the atomic-update benefit concretely, and where the same embedding starts to cost more as the array grows.

// Benefit: this update is atomic — another reader never sees a half-updated items array
db.orders.updateOne({ _id: 1, "items.sku": "X1" }, { $inc: { "items.$.qty": 1 } })

// Cost: as items grows from 3 to 3,000 (e.g. a "cart" that never gets cleared),
// every read and every write of this document moves the whole array, even to change one qty field
db.orders.updateOne({ _id: 1, "items.sku": "X1" }, { $inc: { "items.$.qty": 1 } })
// -> same operation, now rewriting a much larger document each time

1

A single-document update to a nested array element is atomic by default — this is the real benefit, not a marketing simplification.

6

The identical operation on a document that grew unbounded now costs more, because MongoDB still has to read and rewrite the whole containing document.

Why this works: The tradeoff is not "embedding is bad past some size" — it is that the same embedding decision has a cost curve that rises with how much gets embedded, so the "bounded" qualifier on the earlier embed-or-reference decision is what keeps this benefit worth its cost.

What we're doing: Show the extra-query cost concretely, and where reuse pays that cost back.

// A user referenced by 10,000 movie reviews: update once, every reference reflects it
db.users.updateOne({ _id: 987 }, { $set: { bio: "New bio" } })
// -> no need to touch any of the 10,000 movie documents

// Cost: showing a movie WITH the user's name still needs a second query or $lookup
db.movies.aggregate([
  { $match: { _id: 1 } },
  { $lookup: { from: "users", localField: "userId", foreignField: "_id", as: "user" } },
])

1

This is the reuse benefit paying off directly — one update, no fan-out to every document that references this user.

6

This is the matching cost — reading a movie with its user's name now needs a $lookup stage that an embedded snapshot would not have needed.

Why this works: The trade only makes sense when reuse/independent-growth genuinely matters — if this user were referenced by exactly one movie and never updated independently, embedding would give the same correctness with none of the $lookup cost.

What we're doing: Show $slice actively enforcing a bound on an otherwise-growing array, versus a comments array with nothing enforcing one.

// Bounded by $slice: this array can never exceed 5 elements, no matter how many logins happen
db.users.updateOne({ _id: u }, { $push: { recentLogins: { $each: [newEvent], $slice: -5 } } })

// Unbounded: nothing in this operation limits how large "comments" can become
db.posts.updateOne({ _id: p }, { $push: { comments: newComment } })
// -> a popular post can accumulate thousands of comments, each $push moving a larger and larger document

2

$slice: -5 actively enforces the bound — the array is capped by the operation itself, not just by assumption.

5

Nothing here prevents unbounded growth; "popular post" is exactly the case where this array has no natural ceiling.

Why this works: The $slice example shows that "bounded" is not just about small data — it is about whether something in the schema or the update operation actually enforces a limit, versus the array being unbounded in practice even if it happens to be small today.

What we're doing: Show the exact failure mode a design allowed to happen, and the reference-based fix that avoids it entirely.

// The design that allows unbounded growth:
db.posts.updateOne({ _id: p }, { $push: { comments: newComment } })
// -> a popular post's comments array eventually approaches 16 MiB; writes to it start failing

// The fix: comments referenced in their own collection, indexed by postId
db.comments.insertOne({ postId: p, user: u, text: "..." })
db.comments.find({ postId: p }).sort({ createdAt: 1 })   // reads scale independently of the post document

1

This design has no bound on comments — it will work for a long time, then fail, with no warning in between beyond gradually rising latency.

6

Referencing removes the growth risk from the post document entirely — comments now scale as their own collection, with their own index.

Why this works: The fix is the same "reference an unbounded relationship" guidance from the embed-or-reference decision — this concept is about recognizing the concrete failure mode that guidance is protecting against, not a new rule.