Schema Design Patterns
What this domain tests
Schema Design Patterns tests your ability to recognize recurring modeling problems and apply MongoDB's documented patterns. The exam asks which pattern fits a workload and why, so focus on the trade-off each pattern makes between read cost, write cost, and document size.
Patterns to know
- Attribute pattern: move a set of similar fields into an array of key-value documents when there are many optional attributes or when you need to index many fields with few indexes.
- Bucket pattern: group time-series or event data into documents by a time window or entity, storing events in an array with counts and totals.
- Computed pattern: precompute expensive values such as counts, sums, or rankings when reads vastly outnumber writes, and update them on write.
- Subset pattern: keep a small, frequently accessed subset in the main document and the full set in another collection.
- Extended reference pattern: duplicate a few fields from a referenced document to avoid a join on common reads.
- Outlier pattern: handle rare documents that exceed normal bounds with a flag and overflow documents.
- Schema versioning: add a
schemaVersionfield so old and new document shapes coexist during migration.
Worked example
A sensor emits a reading every minute. Instead of one document per reading, use a bucket per sensor per hour: {sensorId, hour, count, sum, readings:[{ts, v}]}. The bucket is bounded at about 60 readings, supports range queries by sensorId and hour, and reduces both document count and index entries. Update count and sum with $inc on each insert.
Traps
Choosing a pattern because it is popular rather than because it matches the access pattern; making buckets unbounded; letting computed fields drift; and forgetting that duplicated fields must be updated when the source changes.