Challenge 3: Identify a Denormalization Trade-off — Possible Solution ==================================================================== WHAT HAPPENS TO EXISTING DOCUMENTS --------------------------------------- Nothing happens to them automatically. Since the supplier's name was embedded directly into each product document (rather than referenced via a supplierId), every existing product document still contains the OLD supplier name, frozen at whatever it was when that product document was last written. Renaming the supplier in a separate "suppliers" record (if one even exists) or updating some central config does nothing to the already-embedded copies — they are now simply STALE, showing outdated information until something explicitly goes back and fixes them. HOW TO ADDRESS IT ------------------------------ There are two realistic options, and the right one depends on how much this staleness actually matters: 1. Run a one-time (or scheduled) bulk update — an updateMany() call that finds every product document referencing this supplier and $set's the embedded name field to the new value. This directly fixes the staleness but requires remembering to do it every time a supplier's name changes. 2. Redesign to REFERENCE the supplier instead of embedding its name — store a supplierId on each product, and look up the supplier's current name from a separate suppliers collection whenever a product is displayed. This permanently eliminates the staleness problem going forward, at the cost of an extra lookup whenever supplier information is needed alongside a product. WHY THIS WORKS AS AN ANSWER ------------------------------ This is exactly the trade-off the chapter described as a DELIBERATE choice, not a flaw to be ashamed of: embedding the supplier's name was presumably chosen because most reads want to see it directly with no extra lookup — but that convenience always comes with exactly this cost when the embedded value can change independently over time. The "right" fix depends on how often suppliers actually rename themselves and how tolerable temporary staleness is for this specific application — there's no universally correct answer, only an explicit trade-off to make consciously rather than stumble into.