Why is the price paid stored on an order document not the same kind of duplication as a copied product name?

## Two values that look the same An order document might contain `productName` and `unitPrice`, both copied from the product document at checkout. On disk they are indistinguishable — two scalars that were read from somewhere else. Semantically they can be opposites, and confusing them is one of the most common modelling mistakes in document databases. ## The deciding question Ask: *if the source value changes, must this value change too?* If the answer is **yes**, the field is a cache of a mutable fact whose home is another document. It has a synchronisation obligation: an owner who updates it, a bound on how stale it may get, and a way to find and repair copies that drifted. This is the field people mean when they talk about denormalization debt. If the answer is **no**, the field is not a copy at all in the semantic sense. It is a distinct fact that this document owns, which merely happened to be derived from another document at a moment in time. The order's price paid, the tax rate applied, the shipping address used, the terms version accepted, the product name as it appeared on the receipt — all of these are facts about the *event*, not about the current state of the referenced entity. Rewriting them to match today's catalogue would falsify history and, in regulated domains, produce an invoice that no longer matches what the customer agreed to. ## Why the distinction matters operationally Get it wrong in the cache direction and you ship silent divergence: a product name that never updates while the product team assumes it does. Get it wrong in the snapshot direction and you ship something worse — a well-intentioned backfill that "repairs" historical orders to the current price, destroying the record of what was actually charged and producing an accounting discrepancy nobody can reconstruct. Backfills are hard to undo because the original value is gone. This is why naming carries real weight here. `unitPrice` on an order is ambiguous and invites a future maintainer to sync it. `unitPriceAtPurchase`, `priceCharged`, `nameOnReceipt` state the intent in the schema itself, where the next reader will see it. A comment in a wiki does not travel with the document; the field name does. ## Snapshot fields still need the reference A point-in-time snapshot does not remove the need for the source identifier. The order still stores `productId` so the current product page can be reached, restocking can be computed, and reporting can group orders by product across renames. The snapshot answers "what did the customer see and agree to"; the reference answers "what is this thing now". Storing only one of the two is a design smell in both directions. ## Mixed documents are normal A single document routinely contains both kinds. An order may hold the price paid (frozen), the shipping address used (frozen), the customer's current loyalty tier for display (a cache that may drift), and the order status (owned outright by the order). A useful discipline is to be able to classify every field of a document into exactly one of three buckets: owned by this document, frozen snapshot of an external fact, or cache of a still-mutable external fact. Only the third bucket generates ongoing maintenance work, and it should be the smallest. ## Versioned sources as a middle path Where the source is genuinely versioned — pricing schedules, terms of service, tax tables — a strong pattern is to store the *identifier of the version* rather than only the value: the order records which price list version applied. That gives an unambiguous, auditable link back to a record that itself never changes, so the value can be recomputed and verified rather than trusted blindly, while still being immune to later edits of the current version. ## How to answer Lead with the test question, classify the two example fields, then make the naming point and note that the reference id stays regardless. Adding the failure mode in each direction — silent drift for a mis-classified cache, a destructive backfill for a mis-classified snapshot — shows you have seen both go wrong.