Challenge 1: Embed or Reference? — Possible Solution
====================================================================

(a) A user's shipping addresses (typically 1-3 per user)
    -> EMBED.
    This is a textbook "one-to-few" case: a small, bounded number of
    addresses that belong conceptually to one user and are almost
    always read together with the rest of that user's profile.
    Embedding as an array of address objects directly on the user
    document is the natural fit.

(b) A YouTube-style video's comments (potentially tens of thousands)
    -> REFERENCE.
    This is a "one-to-squillions" case — the comment count is
    effectively unbounded and can grow very large over a video's
    lifetime. Embedding all of them directly in the video document
    would risk hitting the 16MB document size limit from this
    chapter's gotcha as the video accumulates comments, and loading
    the video would mean loading every comment even if you only want
    to display the first page of them. Comments should live in their
    own collection, referencing the video's id.

(c) A "country" field shared by millions of user documents
    -> REFERENCE (if country carries additional data worth
       centralizing, like a calling code or currency) — though it's
       worth noting that for a SIMPLE country field (just a name or
       ISO code with no other associated data), many real designs
       just embed the plain string value directly, since there's
       nothing meaningfully "shared" to reference — the string
       "Canada" isn't really a relationship the way a category with
       its own tax rate is.
    If country data DOES carry more information (e.g., tax rules,
    supported currencies, shipping restrictions) that might change
    over time and needs to update consistently everywhere at once,
    referencing a shared countries collection avoids exactly the
    "update thousands of documents" problem this chapter's category
    example described.

WHY THIS WORKS AS AN ANSWER
------------------------------
The deciding factors are the same three the chapter introduced: how
much the related data can grow, whether it's shared across many
parents, and whether it's typically read separately from its parent.
(a) fails all three (small, not shared, always read together) →
embed. (b) fails the growth test badly → reference. (c) is genuinely
borderline and depends on whether "country" is really a rich,
shared, changeable entity or just a simple label — which is exactly
why real design decisions like this one require judgment, not a
fixed rule applied blindly.