Generally data modelling is a broad topic to discuss, this is due to many factors that may affect the design decision. One major factor is the application requirements, knowing how the application is going to interact with the database. With MongoDB flexible schema characteristic, developers can focus on the application design and let the database design conform for the benefit of the application. See also :
solutions depend on the specific use case and how you access the data. In case your use cases are “user driven” you may want to embed the prizes. This would be sense full when this is a point in time information, e.g. an order is shipped to a certain address. In case the user moves the address in the order will stay the same. Embedding even makes sense when you have one side of your many sides which is only rarely changing . You gain performance but you have to pay with updating duplication, this again can be done in an off peak time, in case you can accept some hours of stale data.
An other pattern could be the subset pattern, here you keep the latest x records as duplicates, e.g. last ordered items, you’d get the last lets say 10 very quick since they are embedded, if you want to see more than you need to do further reading in a second collection. The cost is again on maintaining the duplication. Again this can be done in off peak time or just with a longer lasting update. You get the idea? (you do not need to keep the data duplicated, you also can spread them in the subset, embedded and the majority in a further collection. If you do this you need to keep this in mind when you access the data on the second collection)
Just step on step back, analyze the workload and access queries and than go for a pattern. $lookup as a subset of an “join” should be the very last resort.