Challenge 3: Justify the Embedding Choice — Possible Solution
====================================================================

Referencing the product instead of embedding a snapshot would mean
each order item stores only a product_id, and the product's current
name/price would be looked up (via $lookup) whenever the order is
displayed.

THE BUG THIS INTRODUCES: a product's price is NOT fixed forever — it
can change after the order was placed (a sale ends, a price increase
goes into effect, etc.). If an order only references the product and
looks up its CURRENT price at display time, then every past order for
that product would appear to have been sold at whatever the price
happens to be TODAY, not what the customer actually paid at the time.
A customer who paid $24.99 last month could open their order history
and see $19.99 (today's sale price) or $29.99 (today's price increase)
listed against an order that already closed — an incorrect historical
record, not just a cosmetic inconsistency.

This is precisely the distinction Step 1 called out explicitly: the
order needs to capture a price_paid SNAPSHOT of what was true at the
moment of purchase, not a live reference to data that keeps changing.
"Keeping it DRY" by referencing instead would remove exactly the
data (name and price AS THEY WERE at checkout) that makes an order
document a trustworthy historical record.

This does mean some duplication — the same product's name is stored
redundantly across every order that included it — but that's a
deliberate, correct trade-off here, not an oversight: it's the same
"embedding is the right fit when data needs to be preserved as it was
at write time" judgment call this course's schema design chapter
(Ch.3) asked readers to make deliberately, not by default.