MongoDB architecture and design mastery covering document schema design, advanced indexing strategies, aggregation pipeline patterns, sharding architecture, replica sets, multi-document transactions, change streams, Atlas cloud features, performance profiling, schema validation, and embedding vs referencing trade-offs.
Use when the user asks about mongodb architect, mongodb architect best practices, or needs guidance on mongodb architect implementation.
Do NOT use when the user needs a different specialized skill or is asking about an unrelated technology domain.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
MongoDB architecture and design mastery covering document schema design, advanced indexing strategies, aggregation pipeline patterns, sharding architecture, replica sets, multi-document transactions, change streams, Atlas cloud features, performance profiling, schema validation, and embedding vs referencing trade-offs.
Use when the user asks about mongodb architect, mongodb architect best practices, or needs guidance on mongodb architect implementation.
Do NOT use when the user needs a different specialized skill or is asking about an unrelated technology domain.
MongoDB schema design is application-driven, not data-driven. Design your documents around your access patterns, not around entity relationships. The cardinal rule: data that is accessed together should be stored together. Every schema decision is a trade-off between read performance, write performance, data consistency, and storage efficiency.
Document Schema Design Patterns
Pattern 1: Embedding (Denormalization)
Embed related data directly within a document when:
The embedded data has a 1:1 or 1:few relationship
The embedded data is always retrieved with the parent
Handle documents with outlier characteristics differently.
// Most books have < 20 reviews, but some have thousands// Normal document:
{ _id: "book1", title: "Normal Book", reviews: [ /* 15 reviews */ ], has_overflow: false }
// Outlier document with overflow:
{ _id: "book2", title: "Popular Book", reviews: [ /* first 100 */ ], has_overflow: true }
{ _id: "book2_overflow_1", parent_id: "book2", reviews: [ /* next 100 */ ] }
Embedding vs Referencing Decision Tree
Will the related data grow unboundedly?
YES -> Reference
NO -> Is the related data > 16MB (document size limit)?
YES -> Reference
NO -> Is the related data updated independently and frequently?
YES -> Reference (to avoid rewriting entire parent)
NO -> Is the related data always accessed with the parent?
YES -> Embed
NO -> Consider both; benchmark with real queries
Indexing Strategies
Index Types
// Single field index
db.users.createIndex({ email: 1 }, { unique: true });
// Compound index (order matters for query coverage)
db.orders.createIndex({ customer_id: 1, created_at: -1 });
// Multikey index (arrays)
db.articles.createIndex({ tags: 1 });
// Text index (full-text search)
db.articles.createIndex({ title: "text", body: "text" },
{ weights: { title: 10, body: 1 } });
// Wildcard index (dynamic schema fields)
db.products.createIndex({ "attributes.$**": 1 });
// Geospatial index
db.stores.createIndex({ location: "2dsphere" });
// Hashed index (for hash-based sharding)
db.users.createIndex({ user_id: "hashed" });
// Partial index (index subset of documents)
db.orders.createIndex(
{ status: 1, created_at: -1 },
{ partialFilterExpression: { status: { $in: ["pending", "processing"] } } }
);
// TTL index (auto-expire documents)
db.sessions.createIndex({ expires_at: 1 }, { expireAfterSeconds: 0 });
ESR Rule for Compound Indexes
Order compound index fields by: Equality, Sort, Range
// Query: find active orders for a customer, sorted by date, in a price range
db.orders.find({
customer_id: "cust_123", // Equalitytotal: { $gte: 50, $lte: 500 } // Range
}).sort({ created_at: -1 }); // Sort// Optimal index: Equality, Sort, Range
db.orders.createIndex({ customer_id: 1, created_at: -1, total: 1 });
Index Analysis
// Check index usage
db.orders.aggregate([
{ $indexStats: {} }
]);
// Explain query plan
db.orders.find({ customer_id: "cust_123" })
.sort({ created_at: -1 })
.explain("executionStats");
// Key metrics to check in explain:// - winningPlan.stage should be IXSCAN (not COLLSCAN)// - executionStats.totalKeysExamined ~= nReturned// - executionStats.totalDocsExamined ~= nReturned
Data Federation: Query across Atlas clusters, S3, and HTTP sources with a unified interface
Online Archive: Automatically tier cold data to cheaper storage while keeping it queryable
Charts: Build dashboards directly from MongoDB data without ETL
When to Use
Use this skill when:
Designing or implementing mongodb architect solutions
Reviewing or improving existing mongodb architect approaches
Making architectural or implementation decisions about mongodb architect
Learning mongodb architect patterns and best practices
Troubleshooting mongodb architect-related issues
Do NOT use this skill when:
The question is about a fundamentally different technology domain
A more specific sibling skill covers the exact topic needed
The user needs a complete hands-on tutorial rather than expert guidance
Output Format
# Mongodb Architect Analysis## Context Assessment
[Situation summary and constraints]
## Recommended Approach
[Primary recommendation with rationale]
## Implementation Steps1. [Step with specific details]
2. [Step with specific details]
3. [Step with specific details]
## Trade-offs and Considerations- [Key trade-off 1]
- [Key trade-off 2]
## Next Steps- [Immediate action item]
- [Follow-up action item]
Example
Input: "Help me implement mongodb architect for a medium-scale production application"
Output: A structured analysis covering current state assessment, recommended mongodb architect approach with specific patterns, implementation roadmap with milestones, and risk mitigation strategies tailored to the application scale and constraints.
Edge Cases
Legacy system integration: When mongodb architect must coexist with legacy approaches, provide a gradual migration path rather than a complete rewrite
Scale mismatch: When the solution complexity exceeds the project scale, recommend a simpler approach and note when to revisit
Team skill gaps: When the team lacks experience with the recommended approach, include learning resources and simpler alternatives
Conflicting requirements: When constraints conflict (e.g., performance vs. maintainability), explicitly state the trade-off and recommend based on stated priorities
