Why should you care?

Rewriting schemas after you have 10 TB is painful. Banks, hospitals, and large SaaS decide boundaries early: what is snapshotted, what is referenced, what is audited.

See it live — copy this example

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

// Tenant-scoped order with snapshot + references
db.orders.insertOne({
  tenantId: "retail-west",
  orderId: "ORD-1001",
  customerId: ObjectId(),
  currency: "INR",
  items: [
    { productId: ObjectId(), sku: "TV-55", name: "4K TV", unitPrice: 42999, qty: 1 }
  ],
  totals: { subtotal: 42999, tax: 7739, grand: 50738 },
  statusHistory: [{ status: "placed", at: new Date() }],
  createdAt: new Date()
})
db.orders.createIndex({ tenantId: 1, createdAt: -1 })
db.orders.createIndex({ tenantId: 1, orderId: 1 }, { unique: true })

Run Example »

Edit the code below and click Run to see the result in Toolliyo’s live editor.

What happened?

• tenantId scopes every order.
• Line items snapshot sku/name/price for invoices.
• statusHistory is a bounded audit trail.
• Indexes support tenant timelines and unique order ids per tenant.

Practice next

1. Write three access patterns for your app on paper.
2. Mark each related field embed vs reference.
3. Add tenantId (or orgId) to all business collections.
4. Add validator requiring tenantId and currency.
5. Move long statusHistory to an orderEvents collection after N entries.

Remember

Start from access patterns and compliance. Snapshot what must not change historically. Index tenant + time (+ business keys).

National retailer order model

Each franchise is a tenant; finance replays orders months later for GST.

Outcome: Snapshots and tenant indexes keep audits correct and fast.