Design documents around your queries, not around tables

The core rule in the MongoDB data modelling docs is: data that is accessed together should be stored together. Before designing collections, list the application's main operations and how often each runs:

1. Which screens or API calls read data, and what do they need in one go?
2. Which writes happen most, and what do they touch?
3. Which relationships are one-to-few, one-to-many or many-to-many?

Then shape documents so the most frequent operations touch one document. A single-document read is one round trip, and a single-document write is atomic without a transaction.

Copying a relational schema one table per collection and joining with $lookup gives you the costs of both models and the benefits of neither.