Step 1 of 5
List the access patterns
MongoDB models are chosen by queries - enumerate them first.
List my app's data access patterns. I will describe the app below. Produce a table: every read pattern (what screen/feature, what it fetches, how filtered/sorted, expected volume) and every write pattern (what creates/updates what, how often). Rank by frequency. These patterns - not entity purity - will drive the model. MY APP: [describe here]
Expected after this step
A ranked table of all read and write patterns.
Should not happen
- ✕Modeling like SQL with joins everywhere
- ✕Unbounded arrays that grow forever inside documents
- ✕No indexes, causing collection scans on every list
- ✕No ownership field, making user scoping impossible
Verify before continuing
Do not move on until every check is true. The complete button stays locked until then.
Do not continue if…
- !Modeling like SQL with joins everywhere
- !Unbounded arrays that grow forever inside documents
- !No indexes, causing collection scans on every list
- !No ownership field, making user scoping impossible
If the AI messes this up
Use this when the AI fakes progress or breaks the feature. It forces a real fix.
The patterns are vague. For each screen write the exact question the database must answer ('newest 20 items for user X where status=active').