Question 23 / 50
An API always $lookups the user onto every order. Would you keep the join, embed the user snapshot, or duplicate a few fields? What factors decide?
Short answer
If the read always needs a stable snapshot (name and address at purchase time), copy those fields onto the order. If it needs live user data, either lookup/populate on a small set or denormalise a cache you are willing to update. Do not $lookup per order on a list of thousands.
Why?
Embedding the whole user on every order duplicates mutable data and bloats documents. Referencing plus lookup is correct when the set is small and indexed. The usual production compromise is a snapshot of the fields the receipt needs, plus userId for later joins. There is no single right answer — the access pattern and freshness requirement decide.
Interview tip
Ask 'does the order need the user as they were, or as they are now?' That question is the answer.
Common mistake
Defaulting to $lookup because 'MongoDB can join now', without talking about list size or freshness.
How did you do?