Why should you care?

Many users can share one product catalog entry. Embedding a full product in every order line would duplicate and go stale; referencing productId stays clean.

See it live — copy this example

Open mongosh or MongoDB Compass, select database nosqlverse, then run the example. Change one field and run again.

const productId = ObjectId()
db.products.insertOne({ _id: productId, name: "Yoga Mat", price: 999 })
db.orders.insertOne({
  userId: ObjectId(),
  productId: productId,
  qty: 2,
  status: "placed"
})
const order = db.orders.findOne({ status: "placed" })
db.products.findOne({ _id: order.productId })

Run Example »

This lesson uses terminal or setup steps. Run commands on your computer — the live editor appears on coding lessons.

What happened?

• products holds the catalog doc.
• orders stores productId only.
• After reading the order, a second findOne loads the product.
• That is manual population — $lookup can automate it later.

Practice next

1. Insert product and order as shown.
2. Read the order, then fetch the product by productId.
3. Change product price and confirm old orders still only store productId (price snapshot is a separate design choice).
4. Store an array of productIds on a wishlist document.
5. Index orders.productId.

Remember

References store ids to other documents. Good for shared or large related data. Resolve with a second query or $lookup.

Shared SKU across carts

Lakhs of carts reference the same productId for a viral SKU.

Outcome: One catalog update to stock is visible everywhere without rewriting carts.