vybekiit 0.4.0 → 0.6.0

package/dist/global-skills/mongodb-schema-design/references/antipattern-excessive-lookups.md

@@ -0,0 +1,84 @@
+---
+title: Reduce Excessive $lookup Usage
+impact: CRITICAL
+impactDescription: "Can reduce query cost on hot paths by avoiding repeated cross-collection joins"
+tags: schema, lookup, anti-pattern, joins, denormalization, atlas-suggestion
+---
+
+## Reduce Excessive $lookup Usage
+
+**Frequent $lookup operations on hot paths can indicate over-normalization.** `$lookup` is useful, but repeated joins can be slower and more resource-intensive than querying a single collection, especially when supporting indexes or match selectivity are weak. If the same related fields are read together often, consider embedding or extended references.
+
+**Incorrect (constant $lookup for common operations):**
+
+```javascript
+// Every product page requires repeated joins across collections
+db.products.aggregate([
+  { $match: { _id: productId } },
+  { $lookup: {
+      from: "categories",          // Collection scan #2
+      localField: "categoryId",
+      foreignField: "_id",
+      as: "category"
+  }},
+  { $lookup: {
+      from: "brands",              // Collection scan #3
+      localField: "brandId",
+      foreignField: "_id",
+      as: "brand"
+  }},
+  { $unwind: "$category" },
+  { $unwind: "$brand" }
+])
+// Multiple join stages add planning/execution overhead on hot paths
+```
+
+Join cost depends on cardinality, stage order, index support, and result size. Measure before deciding to embed.
+
+**Correct (denormalize frequently-joined data):**
+
+Embed data that is always displayed alongside the product directly in the product document: include category fields (`_id`, `name`, `path`) and brand fields (`_id`, `name`, `logo`) as subdocuments. A single indexed query returns complete product data without `$lookup`. Listing queries (e.g. by category) also run against a single collection.
+
+**Managing denormalized data updates:**
+
+When category data changes (a rare event), use `updateMany` to update all products matching that category’s `_id` with the new field values. For frequently-changing data, keep both a reference ID (`brandId`) and a cache subdocument (`brandCache`) with a `cachedAt` timestamp; refresh the cache when it exceeds a staleness threshold.
+
+**When NOT to use this pattern:**
+
+- **Data changes frequently and independently**: If brand logos change daily, denormalization creates update overhead.
+- **Rarely-accessed data**: Don't embed review details if only a small fraction of product views load reviews.
+- **Many-to-many with high cardinality**: Avoid embedding large or fast-growing relationship sets.
+- **Analytics queries**: Batch jobs can afford $lookup latency; real-time queries cannot.
+
+## Verify with
+
+####  Find pipelines with $lookup stages 
+
+For Atlas M10+ use $queryStats. See [Query Stats](references/source-query-stats.md)
+Use codebase if available, ask the user.
+
+```javascript
+
+// Check if $lookup foreign fields are indexed
+
+// Example A - $indexStats
+db.categories.aggregate([
+  { $indexStats: {} }
+])
+
+// Example B - getIndexes()
+db.categories.getIndexes()
+
+// Look for index supporting the query (either a direct index on the foreign field or a compound index that has the foreign field as a prefix, note the collation)
+
+// Measure $lookup impact
+db.products.aggregate([
+  { $match: { category: "electronics" } },
+  { $lookup: { from: "brands", localField: "brandId", foreignField: "_id", as: "brand" } }
+]).explain("executionStats")
+// Check totalDocsExamined in $lookup stage
+```
+
+Atlas Schema Suggestions flags: "Reduce $lookup operations"
+
+Reference: [Reduce Lookup Operations](https://mongodb.com/docs/manual/data-modeling/design-antipatterns/reduce-lookup-operations/)

package/dist/global-skills/mongodb-schema-design/references/antipattern-unnecessary-collections.md

@@ -0,0 +1,91 @@
+---
+title: Reduce Unnecessary Collections
+impact: CRITICAL
+impactDescription: "Reduces avoidable joins when related data is repeatedly queried together"
+tags: schema, collections, anti-pattern, embedding, normalization, atlas-suggestion
+---
+
+## Reduce Unnecessary Collections
+
+**Collection count alone is not the anti-pattern.** The anti-pattern is using collections as a substitute for indexes — creating one collection per category, time period, or partition key instead of indexing a single collection. Every collection carries a default `_id` index that consumes storage and strains the replica set, and cross-collection queries require `$lookup` or `$unionWith`, adding complexity and overhead.
+
+**Incorrect (one collection per day as partitioning strategy):**
+
+Creating one collection per time period (e.g. `temperatures_2024_05_10`, `temperatures_2024_05_11`, …) means each collection carries its own default `_id` index (365 collections/year = 365 extra indexes), cross-day queries require `$unionWith` across many collections, schema validation / indexes / TTL must be duplicated on every collection, and application code must dynamically resolve the collection name for each query.
+
+**Correct (single collection with an index):**
+
+```javascript
+// All readings in one collection — the index does the partitioning work
+{ _id: ObjectId(), timestamp: ISODate("2024-05-10T10:00:00Z"), temperature: 60 }
+{ _id: ObjectId(), timestamp: ISODate("2024-05-10T11:00:00Z"), temperature: 61 }
+{ _id: ObjectId(), timestamp: ISODate("2024-05-11T10:00:00Z"), temperature: 68 }
+
+db.temperatures.createIndex({ timestamp: 1 })
+
+// Efficient range query — one collection, one index
+db.temperatures.find({
+  timestamp: { $gte: ISODate("2024-05-10"), $lt: ISODate("2024-05-11") }
+})
+
+// Optional TTL for automatic expiry (e.g. 90 days)
+db.temperatures.createIndex({ timestamp: 1 }, { expireAfterSeconds: 7776000 })
+```
+
+**Even better (bucket pattern or time series collection):**
+
+For high-volume time-stamped data, group readings into buckets or use a native time series collection, which is optimized for this workload:
+
+```javascript
+// Bucket pattern — one document per day
+{
+  _id: ISODate("2024-05-10T00:00:00Z"),
+  readings: [
+    { timestamp: ISODate("2024-05-10T10:00:00Z"), temperature: 60 },
+    { timestamp: ISODate("2024-05-10T11:00:00Z"), temperature: 61 },
+    { timestamp: ISODate("2024-05-10T12:00:00Z"), temperature: 64 }
+  ]
+}
+
+// In this particular case, a native time series collection
+// is also a good option to consider
+db.createCollection("temperatures", {
+  timeseries: { timeField: "timestamp", granularity: "hours" }
+})
+```
+
+**When to use separate collections:**
+
+| Scenario | Separate Collection | Why |
+|----------|--------------------|----|
+| Data accessed independently | Yes | Different query patterns |
+| Unbounded relationships | Yes | Prevents document growth |
+| Many-to-many | Yes | Students ↔ Courses |
+| 1:1 always together | No (embed) | User and profile |
+
+**When NOT to use this pattern:**
+
+- **Data is genuinely independent**: Products exist separately from orders; don't embed full product catalog in every order.
+- **Frequent independent updates**: If customer email changes shouldn't update all historical orders (it shouldn't).
+- **Data is accessed in different contexts**: Same address entity used for shipping, billing, user profile—keep it separate.
+- **Regulatory requirements**: Some industries require normalized data for audit trails.
+
+## Verify with
+
+```javascript
+// Count your collections
+for (const d of db.adminCommand({ listDatabases: 1 }).databases) {
+  const colls = db.getSiblingDB(d.name).getCollectionNames().length
+  print(`${d.name}: ${colls} collections`)
+}
+// Count alone is not sufficient: combine with access and index/storage evidence
+```
+
+### Check if collections are always accessed together.
+
+For Atlas M10+ use $queryStats. See [Query Stats](references/source-query-stats.md)
+Use codebase if available, ask the user.
+
+Atlas Schema Suggestions flags: "Reduce number of collections"
+
+Reference: [Reduce the Number of Collections](https://mongodb.com/docs/manual/data-modeling/design-antipatterns/reduce-collections/)

package/dist/global-skills/mongodb-schema-design/references/antipattern-unnecessary-indexes.md

@@ -0,0 +1,95 @@
+---
+title: "Avoid Unnecessary Indexes"
+impact: CRITICAL
+impactDescription: "Reduces write overhead and WiredTiger cache pressure from unused or redundant indexes"
+tags: schema, antipattern, indexes, performance, atlas-suggestion
+---
+
+## Avoid Unnecessary Indexes
+
+**Every index has a write cost.** On insert, update, and delete, MongoDB must update ALL indexes on the collection. Unused or redundant indexes slow down writes with no query benefit, and consume RAM in the WiredTiger cache competing with working set data. Atlas Performance Advisor specifically flags "Redundant Index" and "Unused Index".
+
+**Incorrect (indexes created "just in case"):**
+
+```javascript
+// Creating indexes speculatively without query evidence
+db.orders.createIndex({ status: 1 })          // never queried by status alone
+db.orders.createIndex({ status: 1, date: 1 }) // already have {status:1,date:1,amount:1}
+db.orders.createIndex({ region: 1 })           // added during development, never used
+
+// Problems:
+// 1. Every insert/update/delete must update ALL indexes
+// 2. Redundant {status: 1} is fully covered by {status: 1, date: 1, amount: 1}
+// 3. Unused indexes waste RAM in WiredTiger cache
+// 4. Atlas Performance Advisor flags these but they're never cleaned up
+```
+
+**Correct (audit-driven index management):**
+
+```javascript
+// Only create indexes that serve real query patterns
+// Audit before adding new indexes:
+db.orders.aggregate([{ $indexStats: {} }])
+
+// Review index list regularly
+db.orders.getIndexes()
+
+// A compound index {a: 1, b: 1} makes a single-field index {a: 1} redundant
+// — the compound index serves all queries that {a: 1} alone serves
+db.col.createIndex({ a: 1 })         // drop this — redundant
+db.col.createIndex({ a: 1, b: 1 })   // keep this
+
+// NOTE: Different leading field is NOT redundant
+db.col.createIndex({ a: 1, b: 1 })
+db.col.createIndex({ b: 1 })         // NOT covered by above — keep
+```
+
+**Safe removal process (hide → monitor → drop):**
+
+```javascript
+// Never drop an index directly in production
+
+// Step 1: Hide the index (invisible to query planner but stays on disk)
+db.orders.hideIndex("status_1")
+
+// Step 2: Monitor for a full workload cycle (days/weeks)
+// If queries degrade, unhide immediately:
+// db.orders.unhideIndex("status_1")
+
+// Step 3: Once confident, permanently drop
+db.orders.dropIndexes(["status_1"])
+```
+
+Atlas automatically flags:
+- **"Redundant Index"** — a prefix of an existing compound index
+- **"Unused Index"** — zero query usage in the observed window
+
+**When NOT to use this pattern:**
+
+- **New collections with planned queries**: If you know queries are coming, pre-creating indexes is fine.
+- **Indexes for rare but critical operations**: A backup or compliance query that runs monthly may show low usage but is still needed.
+- **TTL indexes**: These serve data lifecycle purposes even if not used for queries.
+
+## Verify with
+
+```javascript
+// Find indexes with zero query usage since last restart
+db.orders.aggregate([{ $indexStats: {} }])
+// Look for: accesses.ops: 0
+// Example output:
+// { name: "status_1", accesses: { ops: 0, since: ISODate("...") }, ... }
+// An accesses.ops: 0 after a representative workload period means the index
+// is never used by any query
+
+// Check total index count and sizes
+db.orders.stats().indexSizes
+// Large number of indexes or large total index size signals audit opportunity
+
+// Find redundant indexes (prefix subsets)
+for (const idx of db.orders.getIndexes()) {
+  print(`${idx.name}: ${JSON.stringify(idx.key)}`)
+}
+// Compare index key prefixes — if {a:1} exists alongside {a:1,b:1}, the former is redundant
+```
+
+Reference: [Remove Unnecessary Indexes](https://mongodb.com/docs/manual/data-modeling/design-antipatterns/unnecessary-indexes/)

package/dist/global-skills/mongodb-schema-design/references/fundamental-document-model.md

@@ -0,0 +1,91 @@
+---
+title: Embrace the Document Model
+impact: HIGH
+impactDescription: "Aligns schema to aggregate access patterns and minimizes avoidable cross-collection joins"
+tags: schema, document-model, fundamentals, sql-migration
+---
+
+## Embrace the Document Model
+
+**Don't recreate SQL tables one-to-one in MongoDB.** The document model is designed to store related data together when it is read and updated together. Naively copying relational boundaries often increases application-side joins and coordination logic.
+
+**Incorrect (SQL patterns in MongoDB):**
+
+Mirroring a relational schema 1:1 — e.g. separate `customers`, `addresses`, `phones`, and `preferences` collections linked by `customerId` — requires four queries and four index lookups to load one customer profile, plus application-side joining. Updates may require cross-collection coordination or transactions.
+
+**Correct (rich document model):**
+
+```javascript
+// Customer document contains everything about the customer
+// All data retrieved in single read, updated atomically
+{
+  _id: "cust123",
+  name: "Alice Smith",
+  email: "alice@example.com",
+  addresses: [
+    { type: "home", street: "123 Main", city: "Boston", zip: "02101" },
+    { type: "work", street: "456 Oak", city: "Boston", zip: "02102" }
+  ],
+  phones: [
+    { type: "mobile", number: "555-1234" },
+    { type: "work", number: "555-5678" }
+  ],
+  preferences: {
+    newsletter: true,
+    theme: "dark",
+    language: "en"
+  },
+  createdAt: ISODate("2024-01-01")
+}
+
+// Single query loads complete customer - 1 round-trip
+db.customers.findOne({ _id: "cust123" })
+
+// Atomic update - no transaction needed
+db.customers.updateOne(
+  { _id: "cust123" },
+  { $push: { addresses: newAddress }, $set: { "preferences.theme": "light" } }
+)
+```
+
+**Common tradeoffs:**
+
+| Aspect | SQL-style mapping in MongoDB | Document-first mapping |
+|--------|----------------------------|------------------------|
+| Queries per aggregate view | Often multiple collection reads or `$lookup` | Often one collection read for hot paths |
+| Atomicity for related fields | May require multi-document transaction | Single-document writes are atomic |
+| Schema evolution | More migration/coordination between collections | Often localized changes per document shape |
+| Application logic | More join/merge logic in app | Simpler read model for common operations |
+
+**When migrating from SQL:**
+
+1. Don't convert tables 1:1 to collections
+2. Identify which tables are always joined together
+3. Denormalize those joins into single documents
+4. Keep separate only what's accessed separately
+
+**When NOT to use this pattern:**
+
+- **Genuinely independent data**: If addresses are shared across users or accessed independently, keep them separate.
+- **Unbounded relationships**: User with 10,000 orders should NOT embed all orders.
+- **Regulatory requirements**: Some compliance rules require normalized audit trails.
+
+## Verify with
+
+```javascript
+// Count your collections vs expected entities
+for (const d of db.adminCommand({ listDatabases: 1 }).databases) {
+  const colls = db.getSiblingDB(d.name).getCollectionNames().length
+  print(`${d.name}: ${colls} collections`)
+}
+// Collection count alone is not enough evidence; inspect query/access patterns too
+
+// Check for SQL-style foreign key patterns
+db.addresses.aggregate([
+  { $group: { _id: "$customerId", count: { $sum: 1 } } },
+  { $match: { count: { $gt: 0 } } }
+]).itcount()
+// If addresses always belong to customers, they should be embedded
+```
+
+Reference: [Schema Design Process](https://mongodb.com/docs/manual/data-modeling/schema-design-process/)

package/dist/global-skills/mongodb-schema-design/references/fundamental-document-size.md

@@ -0,0 +1,226 @@
+---
+title: Keep Documents Small
+impact: CRITICAL
+impactDescription: "Hard 16MB BSON limit; oversized documents fail writes and degrade performance long before that"
+tags: schema, fundamentals, document-size, 16mb, bson-limit, arrays, anti-pattern, performance, indexing, subset-pattern, working-set, hot-data, cold-data, atlas-suggestion
+---
+
+## Keep Documents Small
+
+**MongoDB documents cannot exceed 16 megabytes.** This is a hard BSON limit, not a guideline — writes fail once a document reaches it.
+
+However, practical documents should be **much smaller than 16MB**. As a rule of thumb, aim for documents **under 1MB**. Smaller documents mean:
+
+- **Better working-set efficiency** — more documents fit in the WiredTiger cache.
+- **Faster reads and writes** — less data copied, serialized, and transferred per operation.
+- **Lower replication overhead** — smaller oplog entries replicate faster.
+- **Room to grow** — a document well under the limit won't surprise you after a year of appended data.
+
+The 16MB ceiling is a safety net, not a design target.
+
+### How documents get too large
+
+1. **Unbounded arrays** — e.g. an `activityLog` array receiving entries on every user action: 100,000 events × ~150 bytes ≈ 15MB, growing until writes are rejected.
+2. **Large bounded arrays** — even a bounded comments array (5,000 items × ~500 bytes = 2.5MB) is expensive: each `$push` rewrites the growing document, and a multikey index fans out to one entry per element.
+3. **Bloated documents with cold fields** — MongoDB reads full documents, even when queries only need a few fields. A product document carrying name and price (~18 bytes, frequently needed) alongside description (~5KB), full specs (~10KB), base64 images (~500KB), reviews (~100KB), and price history (~50KB) can reach ~665KB. Hot-path queries still load the entire document into cache, reducing working-set density. Even projecting a small field set (e.g. `db.products.find({}, {name: 1, price: 1})`) still reads the full document from storage.
+4. **Large embedded binary** — a `BinData` PDF attachment of 10MB+; additional attachments push the document past the limit.
+5. **Deeply nested objects** — a configuration document with 100+ nesting levels where metadata and keys alone approach 16MB.
+
+### Solution 1: move unbounded or large data to a separate collection
+
+Keep the parent document small. Store children in their own collection with a reference field and a compound index for efficient queries.
+
+```javascript
+// Parent stays lean
+{ _id: "user123", name: "Alice", activityCount: 48210, lastActivity: ISODate("...") }
+
+// Children in separate collection with efficient index
+// Index: { userId: 1, ts: -1 }
+{ userId: "user123", action: "login", ts: ISODate("...") }
+```
+
+For large binary blobs, use GridFS for in-database storage, or — often more efficient — store them in external object storage and keep only a reference in MongoDB.
+
+### Solution 2: split hot and cold fields (Subset Pattern)
+
+Keep frequently-accessed (hot) data in the main document; store rarely-accessed (cold) data in a separate collection. This dramatically improves cache density for hot-path queries.
+
+**Incorrect (all data in one document):** A movie document with all 10,000 reviews embedded (~1MB of cold data alongside ~1KB of hot data like title, rating, plot) means every page load pulls ~1MB into RAM. Most page views only need title + rating + plot, so this reduces how many movies fit in cache (e.g. 1GB RAM ≈ 1,000 movies instead of ~1,000,000 if only hot data were loaded).
+
+**Correct (subset pattern):** The movie document (~2KB) contains only hot fields: `title`, `year`, `rating`, `plot`, `reviewStats` (count, avgRating, distribution), and a bounded `featuredReviews` array (top 5 only, ~500 bytes). Full reviews live in a separate `reviews` collection with `movieId` reference, loaded only when the user clicks "Show all reviews."
+
+Similarly, a product document should keep only hot fields in the main document (~500 bytes): name, price, thumbnail URL, avgRating, reviewCount, inStock. Move cold data to separate collections — `products_details` (description, fullSpecs), `products_images` (images array), `products_reviews` (paginated reviews).
+
+**How to identify hot vs cold data:**
+
+| Hot Data (embed) | Cold Data (separate) |
+|------------------|----------------------|
+| Displayed on every page load | Only on user action (click, scroll) |
+| Used for filtering/sorting | Historical/archival |
+| Small relative size | Large relative size |
+| Bounded small subsets | Large or unbounded sets |
+| Changes rarely | Changes frequently |
+
+**Maintaining an embedded subset:**
+
+```javascript
+// When a new review is added:
+// 1. Insert full review into reviews collection
+db.reviews.insertOne({ movieId: "movie123", user: "newUser", rating: 5, text: "Amazing!", date: new Date(), helpful: 0 })
+
+// 2. Update movie stats
+db.movies.updateOne(
+  { _id: "movie123" },
+  { $inc: { "reviewStats.count": 1, "reviewStats.distribution.5": 1 } }
+)
+
+// 3. Periodically refresh featured reviews (background job)
+const topReviews = db.reviews.find({ movieId: "movie123" }).sort({ helpful: -1 }).limit(5).toArray()
+db.movies.updateOne({ _id: "movie123" }, { $set: { featuredReviews: topReviews } })
+```
+
+For arrays, atomic `$slice` keeps the embedded subset bounded without a background job:
+
+```javascript
+db.posts.updateOne(
+  { _id: "post123" },
+  {
+    $push: {
+      recentComments: {
+        $each: [newComment],
+        $slice: -20,
+        $sort: { ts: -1 }
+      }
+    },
+    $inc: { commentCount: 1 }
+  }
+)
+// Also insert into overflow comments collection
+db.comments.insertOne({ postId: "post123", ...newComment })
+```
+
+### Solution 3: projection (when you can't refactor)
+
+```javascript
+// Only transfers ~500 bytes instead of 665KB over the network
+db.products.find(
+  { category: "electronics" },
+  { name: 1, price: 1, thumbnail: 1 }
+)
+```
+
+Projection reduces network transfer but still loads full documents into memory unless the query is fully covered by an index. For real working-set reduction, split hot and cold data into separate collections.
+
+### Prevention strategies
+
+```javascript
+// 1. Schema validation with array limits
+db.createCollection("users", {
+  validator: {
+    $jsonSchema: {
+      properties: {
+        addresses: { maxItems: 10 },
+        tags: { maxItems: 100 }
+      }
+    }
+  }
+})
+// (See fundamental-schema-validation.md for full validation guidance).
+
+// 2. Application-level checks before write
+const doc = await db.users.findOne({ _id: userId })
+const currentSize = BSON.calculateObjectSize(doc)
+if (currentSize > 200 * 1024) {  // 200KB warning — well before trouble
+  logger.warn("Document size exceeding recommended threshold")
+}
+
+// 3. Use $slice to cap arrays
+db.users.updateOne(
+  { _id: userId },
+  {
+    $push: {
+      activityLog: {
+        $each: [newActivity],
+        $slice: -1000  // Keep only last 1000
+      }
+    }
+  }
+)
+```
+
+### Workload signals
+
+| Signal | Action |
+|--------|--------|
+| Array cardinality keeps growing | Cap with `$slice` or move to separate collection |
+| Array field is heavily indexed | Review multikey fan-out; move cold data out |
+| Reads only need recent subset | Embed recent N, reference full history |
+| Updates slow as array grows | Switch to referenced write path |
+| Documents routinely exceed ~200KB | Reassess schema — consider splitting hot/cold |
+| WiredTiger cache pressure is high | Check for bloated documents; split candidates |
+
+### When keeping data together is fine
+
+- **Small, bounded arrays** — tags (max 20), roles (max 5), addresses (max 10) with a hard limit.
+- **Write-once arrays** — built once and never modified; size still affects working set.
+- **Arrays of primitives** — `tags: ["a", "b", "c"]` is much cheaper than arrays of objects.
+- **Small collections that fit in RAM** — if your entire collection is <1GB, document size matters less.
+- **Always need all data** — if every access pattern truly needs the full document, splitting adds overhead.
+
+## Verify with
+
+```javascript
+// Find largest documents in collection
+db.collection.aggregate([
+  { $project: { size: { $bsonSize: "$$ROOT" } } },
+  { $sort: { size: -1 } },
+  { $limit: 10 }
+])
+
+// Check specific field sizes to find bloat
+db.collection.aggregate([
+  { $project: {
+    total: { $bsonSize: "$$ROOT" },
+    activitySize: { $bsonSize: { $ifNull: ["$activityLog", []] } },
+    profileSize: { $bsonSize: { $ifNull: ["$profile", {}] } }
+  }}
+])
+
+// Find documents with large arrays
+db.collection.aggregate([
+  { $project: {
+    size: { $bsonSize: "$$ROOT" },
+    arrayLen: { $size: { $ifNull: ["$myArray", []] } }
+  }},
+  { $match: { arrayLen: { $gt: 100 } } },
+  { $sort: { arrayLen: -1 } },
+  { $limit: 10 }
+])
+
+// Find documents with hot/cold imbalance
+db.collection.aggregate([
+  { $project: {
+    totalSize: { $bsonSize: "$$ROOT" },
+    coldSize: { $bsonSize: { $ifNull: ["$reviews", []] } },
+    hotSize: { $subtract: [
+      { $bsonSize: "$$ROOT" },
+      { $bsonSize: { $ifNull: ["$reviews", []] } }
+    ]}
+  }},
+  { $match: {
+    $expr: { $gt: ["$coldSize", { $multiply: ["$hotSize", 10] }] }
+  }},
+  { $limit: 10 }
+])
+
+// Check working set vs RAM
+db.serverStatus().wiredTiger.cache
+// "bytes currently in the cache" vs "maximum bytes configured"
+```
+
+Atlas Schema Suggestions flags: "Array field may grow without bound", "Document size exceeds recommended limit"
+
+References:
+- [BSON Document Size Limit](https://mongodb.com/docs/manual/reference/limits/#std-label-limit-bson-document-size)
+- [Avoid Unbounded Arrays](https://mongodb.com/docs/manual/data-modeling/design-antipatterns/unbounded-arrays/)
+- [Reduce Bloated Documents](https://mongodb.com/docs/manual/data-modeling/design-antipatterns/bloated-documents/)