Challenge 3: Spot the Embedding Refactor — Possible Solution
====================================================================

WHAT BREAKS: 40,000 comments embedded in one post document is a
textbook case of the "unbounded array growth" signal. Concretely:

1. The post document is at real risk of approaching or exceeding
   MongoDB's hard 16MB per-document size limit — even short comments
   average out to real bytes at that volume, and there's no guarantee
   commenters stay short.
2. Every single read of the post — even a reader who only wants the
   title and body, never scrolling to comments — has to load all
   40,000 embedded comments along with it, since embedding means
   "always read together."
3. Adding one new comment means updating (rewriting part of) an
   already-enormous document, which gets slower and more
   write-contention-prone as the array grows, especially if many
   people are commenting on the same viral post at once.

WHAT THE SCHEMA SHOULD CHANGE TO: split comments into their own
collection, referencing the post by ID — the exact refactor path this
chapter names.

  { _id: ObjectId("..."), post_id: "P_viral", author: "Dana",
    text: "...", postedAt: ISODate("2026-07-06") }

Fetching a post no longer drags all its comments along automatically;
fetching comments becomes its own query — find({ post_id: "P_viral" })
— which can be paginated (e.g. 20 at a time) instead of forcing all
40,000 to load at once, and a $lookup can still join them back to the
post on the occasions a full view genuinely needs both together.

This is precisely the same trade-off mongodb1-1's original embedding
example accepted for a small, bounded number of comments — the design
was reasonable then; 40,000 comments later, it no longer is.