MongoDB Data Model Plan

The route

5 steps to Done

1. 01

   List the access patterns

   MongoDB models are chosen by queries - enumerate them first.

   Preview prompt + verify gate ▾ Hide ▴

   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]

   • ✓ Every screen's data needs appear
   • ✓ Filters and sorts are specified
   • ✓ Patterns are ranked by frequency
2. 02

   Decide embed vs reference

   The core MongoDB decision, made per relationship with reasoning.

   Preview prompt + verify gate ▾ Hide ▴

   Design the collections. For each relationship decide embed vs reference using: read-together data embeds (if bounded and owned); independently-queried, unbounded, or shared data references. Document each decision with its reason and the risk if wrong. Define every collection's document shape with field types, the owner field (userId) on user data, and createdAt/updatedAt.

   • ✓ Each relationship has a stated reason
   • ✓ No unbounded embedded arrays
   • ✓ Owner and timestamp fields present
3. 03

   Plan the indexes

   Every frequent query gets an index - designed, not guessed.

   Preview prompt + verify gate ▾ Hide ▴

   Plan the indexes from the access patterns: for each frequent query define the index (compound where filter+sort combine - equality fields first, then sort fields), unique indexes for natural keys (email, slug), and any text index needed for search. State which pattern each index serves. Flag queries that would still scan and adjust the model or index.

   • ✓ Each frequent pattern has an index
   • ✓ Compound order follows equality-then-sort
   • ✓ Unique constraints identified
4. 04

   Implement with validation

   Create the collections, indexes, and a validation layer.

   Preview prompt + verify gate ▾ Hide ▴

   Implement the model: create indexes on startup (idempotent); implement validation - either application-level schemas (e.g. Pydantic models) validating every write, or MongoDB JSON Schema validators on the collections (choose and justify); ensure ObjectId/UUID and datetime handling is consistent (serialization-safe for the API); write one create+read per collection proving the shape round-trips.

   • ✓ Index creation is idempotent on startup
   • ✓ Malformed writes are rejected
   • ✓ Dates and ids serialize cleanly through the API
5. 05

   Test against real queries

   Prove the model with the app's actual operations at realistic volume.

   Preview prompt + verify gate ▾ Hide ▴

   Test the model: run every access pattern from step 1 against the implemented collections (with a few hundred seeded documents for realism); verify results, sort orders, and user scoping; check explain plans on the heavy queries (indexes used, no full scans); document the final model (collections, shapes, indexes, validation) as the schema reference.

   • ✓ Every pattern was executed
   • ✓ Explain plans show index usage
   • ✓ Final model documented