{"title":"MongoDB Deep Dive","description":"","content":"MongoDB is useful when the data model is naturally document-shaped: profiles, carts, catalogs, activity records, content metadata, and other objects that are usually read and written as a unit.\n\n\n\n\n\nIt sits between simple key-value stores and relational databases: richer queries than a key-value store, more schema flexibility than SQL, and built-in sharding when one machine is no longer enough.\n\nThat flexibility does not remove the need for modeling. The main design work is deciding what to embed, what to reference, which indexes to maintain, and which shard key will avoid hot spots.\n\n---\n\n# MongoDB Architecture Overview\n\nA sharded MongoDB cluster has three distinct layers: application-facing routers, a config server replica set that holds routing metadata, and the data shards, each of which runs its own replica set for availability. The diagram maps how these layers connect and how writes and reads flow from client to storage:\n\n\n```mermaid\nflowchart LR\n subgraph Client[\"Application Layer\"]\n A1[App Server 1]:::primary\n A2[App Server 2]:::primary\n A3[App Server N]:::primary\n end\n\n subgraph Routers[\"Query Routers\"]\n M1[mongos]:::orange\n M2[mongos]:::orange\n end\n\n subgraph Config[\"Config Servers (Replica Set)\"]\n C1[Config 1]:::teal\n C2[Config 2]:::teal\n C3[Config 3]:::teal\n end\n\n subgraph Shard1[\"Shard 1 (Replica Set)\"]\n S1P[Primary]:::green\n S1S1[Secondary]:::green\n S1S2[Secondary]:::green\n end\n\n subgraph Shard2[\"Shard 2 (Replica Set)\"]\n S2P[Primary]:::green\n S2S1[Secondary]:::green\n S2S2[Secondary]:::green\n end\n\n A1 --> M1\n A2 --> M1\n A3 --> M2\n M1 --> C1\n M2 --> C2\n M1 --> S1P\n M1 --> S2P\n M2 --> S1P\n M2 --> S2P\n S1P --> S1S1\n S1P --> S1S2\n S2P --> S2S1\n S2P --> S2S2\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nApplication servers don’t talk to shard nodes directly. They connect to **mongos query routers** (M1/M2). `mongos` is the stateless front door of a sharded MongoDB cluster: it accepts client requests, consults cluster metadata, and routes each operation to the right shard(s).\n\nThat routing metadata lives on the **config servers**, which run as a **replica set** (C1/C2/C3) for high availability. Config servers store the cluster’s sharding configuration: which collections are sharded, the shard key ranges (chunks), and which shard owns which chunk. `mongos` reads this metadata to decide where a query or write should go.\n\nEach shard (Shard 1 and Shard 2) is itself a **replica set**:\n\n- a **Primary** node handles all writes (and can serve reads, depending on read preference)\n- **Secondary** nodes replicate from the primary and can serve read traffic if configured\n- if the primary fails, the replica set elects a new primary automatically\n\nFor a request flow:\n\n- **Writes** go through `mongos` to the primary of the target shard (chosen by the shard key). The primary then replicates the operation to its secondaries.\n- **Reads** go through `mongos` as well. If the query includes the shard key (or is otherwise targeted), `mongos` routes it to the relevant shard. If not, it may do a **scatter-gather** across shards and merge results.\n- Replication within each shard provides **availability**, while sharding across shards provides **horizontal scale** for data size and throughput.\n\n---\n\n# 1. When to Choose MongoDB\n\nChoose MongoDB when the application mostly works with whole documents and the schema changes often. Avoid choosing it just because it is \"schemaless\"; poor modeling still creates slow queries, duplicated updates, and painful shard keys.\n\n### 1.1 Choose MongoDB When You Have\n\n#### Flexible or evolving schemas\n\nYour data structure changes frequently, or different records have different fields. MongoDB does not require schema migrations for adding new fields.\n\n#### Document-centric data\n\nYour data naturally forms self-contained documents (articles, products, user profiles) rather than highly normalized relations.\n\n#### Rich query requirements\n\nYou need complex queries, aggregations, full-text search, or geospatial queries beyond simple key-value lookups.\n\n#### Rapid development\n\nYou are building a prototype or MVP where schema flexibility accelerates iteration.\n\n#### Hierarchical or nested data\n\nYour data has natural nesting (comments within posts, items within orders) that would require multiple joins in SQL.\n\n#### Horizontal scaling needs\n\nYou anticipate needing to scale beyond a single server with built-in sharding support.\n\n\n```mermaid\nflowchart TD\n A[Is your data document-centric?]:::primary\n A -->|Yes| B[Need flexible schema?]:::primary\n A -->|No| C[Consider Relational DB]:::red\n B -->|Yes| D[Need rich queries?]:::primary\n B -->|No| E[Consider DynamoDB]:::orange\n D -->|Yes| F[MongoDB is a good fit]:::green\n D -->|No| G[Need massive scale?]:::primary\n G -->|Yes| H[Consider DynamoDB or Cassandra]:::orange\n G -->|No| F\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\n### 1.2 Avoid MongoDB When You Need\n\n#### Complex multi-table transactions\n\nWhile MongoDB supports transactions, it is not optimized for workloads with frequent cross-collection transactions like banking systems.\n\n#### Highly relational data\n\nIf your data requires many relationships and frequent joins across entities, a relational database with proper foreign keys is cleaner.\n\n#### Strong schema enforcement\n\nWhen data integrity is critical and you need strict validation, PostgreSQL's constraints are stronger.\n\n#### Simple key-value access\n\nIf you only need primary key lookups at massive scale, DynamoDB or Redis is more efficient.\n\n#### Heavy analytics workloads\n\nFor OLAP queries over large datasets, data warehouses like Redshift or BigQuery are better suited.\n\n### 1.3 Common Interview Systems Using MongoDB\n\n\n| System | Why MongoDB Works |\n|--------|-------------------|\n| Content Management System | Flexible schema for diverse content types |\n| E-commerce Product Catalog | Products with varying attributes |\n| Social Network | User profiles, posts, comments with nested data |\n| Real-time Analytics Dashboard | Aggregation framework, time-series support |\n| Mobile App Backend | Schema flexibility, offline sync with Realm |\n| Gaming User Profiles | Complex nested data, frequent schema changes |\n\n\n# 2. Data Modeling: Embedding vs Referencing\n\nIf you approach MongoDB with relational database thinking, you will end up with the worst of both worlds: the operational complexity of a document database without the query flexibility of a relational one. \n\nThe fundamental modeling decision in MongoDB is whether to embed related data within a document or reference it in a separate collection. This choice affects query performance, data consistency, and application complexity. There is no universally correct answer, only trade-offs that favor different access patterns.\n\n### 2.1 Embedding (Denormalization)\n\nStore related data together in a single document.\n\n\n```json\n{\n \"_id\": \"order_123\",\n \"customer\": {\n \"name\": \"John Doe\",\n \"email\": \"john@example.com\"\n },\n \"items\": [\n {\"product\": \"Laptop\", \"price\": 999, \"quantity\": 1},\n {\"product\": \"Mouse\", \"price\": 29, \"quantity\": 2}\n ],\n \"shipping_address\": {\n \"street\": \"123 Main St\",\n \"city\": \"San Francisco\",\n \"zip\": \"94102\"\n },\n \"total\": 1057,\n \"status\": \"shipped\"\n}\n```\n\n\n#### Advantages\n\n- Single read retrieves all data (no joins)\n- Atomic updates on the entire document\n- Better read performance for common access patterns\n- Simpler application code\n\n#### Disadvantages\n\n- Data duplication if embedded data is shared\n- Document size limit (16 MB)\n- Updates to shared data require updating multiple documents\n\n### 2.2 Referencing (Normalization)\n\nStore related data in separate collections with references.\n\n\n```json\n// Orders collection\n{\n \"_id\": \"order_123\",\n \"customer_id\": \"customer_456\",\n \"item_ids\": [\"item_1\", \"item_2\"],\n \"total\": 1057,\n \"status\": \"shipped\"\n}\n\n// Customers collection\n{\n \"_id\": \"customer_456\",\n \"name\": \"John Doe\",\n \"email\": \"john@example.com\"\n}\n\n// Items collection\n{\n \"_id\": \"item_1\",\n \"order_id\": \"order_123\",\n \"product\": \"Laptop\",\n \"price\": 999\n}\n```\n\n\n#### Advantages\n\n- No data duplication\n- Smaller document sizes\n- Easier to update shared data\n- Better for many-to-many relationships\n\n#### Disadvantages\n\n- Requires multiple queries or $lookup\n- No atomic operations across collections (without transactions)\n- More complex application code\n\n### 2.3 Decision Framework\n\nThe right choice between embedding and referencing depends on access patterns, relationship cardinality, and whether the child data can grow without bound. This decision tree walks through those questions in order:\n\n\n```mermaid\nflowchart TD\n A[How is data accessed?]:::primary\n A --> B{Always together?}:::yellow\n B -->|Yes| C[Embed]:::green\n B -->|No| D{One-to-many?}:::yellow\n D -->|Few children| E[Embed array]:::green\n D -->|Many children| F{Unbounded growth?}:::yellow\n F -->|Yes| G[Reference]:::orange\n F -->|No| H[Embed with limit]:::green\n D -->|Many-to-many| I[Reference]:::orange\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef yellow fill:#ffd43b,stroke:#000,color:#000\n```\n\n\n#### Embed when\n\n- Data is accessed together (1:1 or 1:few relationships)\n- Child data does not make sense outside parent context\n- Data does not change frequently\n- Array will not grow unbounded\n\n#### Reference when\n\n- Data is accessed independently\n- Many-to-many relationships exist\n- Child collection can grow unbounded\n- Data is frequently updated across many parents\n\n### 2.4 Hybrid Approach\n\nOften the best solution combines both strategies:\n\n\n```json\n// Order document with embedded items but referenced customer\n{\n \"_id\": \"order_123\",\n \"customer_id\": \"customer_456\",\n \"customer_snapshot\": {\n \"name\": \"John Doe\",\n \"email\": \"john@example.com\"\n },\n \"items\": [\n {\"product_id\": \"prod_1\", \"name\": \"Laptop\", \"price\": 999, \"quantity\": 1}\n ],\n \"total\": 1057\n}\n```\n\n\nThis approach embeds the data needed for display (customer_snapshot), references the canonical data that might change (customer_id), and keeps related items together for atomic updates.\n\n\n> **TIP**\n>\n> **Design note:** Choose embedding or referencing from access patterns. In an order system, line items are usually embedded because they are fetched with the order, rarely queried independently, and useful for computing totals inside one document.\n>\n> For users and addresses, references may be cleaner if users can have many addresses, addresses change independently, or the same address is shared by multiple accounts.\n\n\n---\n\n# 3. Schema Design Patterns\n\nEmbedding and referencing cover the basics. The next step is recognizing recurring modeling problems: documents with widely varying attributes, high-frequency time-series data, and outlier records that would otherwise make typical documents too large.\n\nKnowing these patterns, and when each applies, demonstrates practical experience beyond textbook knowledge.\n\n### 3.1 Attribute Pattern\n\n**Problem:** Documents have many similar fields, or fields vary between documents.\n\n**Solution:** Move sparse attributes to an array of key-value pairs.\n\n\n```json\n// Before: Sparse attributes\n{\n \"name\": \"Laptop\",\n \"screen_size\": \"15.6\",\n \"ram\": \"16GB\",\n \"storage\": \"512GB SSD\",\n \"graphics_card\": \"RTX 3060\",\n \"color\": null,\n \"material\": null\n}\n\n// After: Attribute pattern\n{\n \"name\": \"Laptop\",\n \"attributes\": [\n {\"key\": \"screen_size\", \"value\": \"15.6\"},\n {\"key\": \"ram\", \"value\": \"16GB\"},\n {\"key\": \"storage\", \"value\": \"512GB SSD\"},\n {\"key\": \"graphics_card\", \"value\": \"RTX 3060\"}\n ]\n}\n```\n\n\n#### Benefits\n\n- Index on `attributes.key` and `attributes.value` covers all attributes\n- No null fields wasting space\n- Easy to add new attributes\n\n**Use case:** Product catalogs with varying specifications.\n\n### 3.2 Bucket Pattern\n\n**Problem:** High-frequency time-series data creates too many documents.\n\n**Solution:** Group multiple data points into time-based buckets.\n\n\n```json\n// Before: One document per reading\n{\"sensor_id\": \"S1\", \"timestamp\": \"2024-01-15T10:00:00Z\", \"value\": 23.5}\n{\"sensor_id\": \"S1\", \"timestamp\": \"2024-01-15T10:00:01Z\", \"value\": 23.6}\n// ... millions of documents\n\n// After: Bucket pattern (1 hour per document)\n{\n \"sensor_id\": \"S1\",\n \"bucket_start\": \"2024-01-15T10:00:00Z\",\n \"bucket_end\": \"2024-01-15T11:00:00Z\",\n \"readings\": [\n {\"offset\": 0, \"value\": 23.5},\n {\"offset\": 1, \"value\": 23.6},\n {\"offset\": 2, \"value\": 23.4}\n ],\n \"count\": 3600,\n \"sum\": 84600,\n \"min\": 22.1,\n \"max\": 25.3\n}\n```\n\n\n#### Benefits\n\n- Fewer documents (better index efficiency)\n- Pre-computed aggregates for common queries\n- Controlled document size\n\n**Use case:** IoT sensor data, application metrics, time-series analytics.\n\n### 3.3 Outlier Pattern\n\n**Problem:** Most documents are small, but a few are extremely large.\n\n**Solution:** Handle outliers separately with overflow documents.\n\n\n```json\n// Regular book with few reviews\n{\n \"_id\": \"book_normal\",\n \"title\": \"Regular Book\",\n \"reviews\": [\n {\"user\": \"A\", \"rating\": 4, \"text\": \"Good\"},\n {\"user\": \"B\", \"rating\": 5, \"text\": \"Great\"}\n ],\n \"has_overflow\": false\n}\n\n// Popular book with too many reviews\n{\n \"_id\": \"book_popular\",\n \"title\": \"Bestseller\",\n \"reviews\": [/* first 100 reviews */],\n \"has_overflow\": true\n}\n\n// Overflow document\n{\n \"_id\": \"book_popular_overflow_1\",\n \"book_id\": \"book_popular\",\n \"reviews\": [/* next 100 reviews */]\n}\n```\n\n\n#### Benefits\n\n- Most queries work on compact documents\n- Outliers handled without penalizing normal cases\n- Avoids 16 MB document limit\n\n**Use case:** Social media posts with viral engagement, products with many reviews.\n\n### 3.4 Computed Pattern\n\n**Problem:** Expensive computations run repeatedly on the same data.\n\n**Solution:** Pre-compute and store results, update on writes.\n\n\n```json\n{\n \"_id\": \"product_123\",\n \"name\": \"Laptop\",\n \"reviews\": [\n {\"rating\": 5}, {\"rating\": 4}, {\"rating\": 5}, {\"rating\": 3}\n ],\n \"computed\": {\n \"review_count\": 4,\n \"average_rating\": 4.25,\n \"rating_distribution\": {\"5\": 2, \"4\": 1, \"3\": 1, \"2\": 0, \"1\": 0},\n \"last_computed\": \"2024-01-15T10:00:00Z\"\n }\n}\n```\n\n\n#### Benefits\n\n- Reads are instant (no aggregation needed)\n- Trade write complexity for read performance\n- Can be updated incrementally or periodically\n\n**Use case:** Dashboards, product ratings, leaderboards.\n\n### 3.5 Extended Reference Pattern\n\n**Problem:** Frequent joins to fetch commonly needed fields from referenced documents.\n\n**Solution:** Copy frequently accessed fields into the referencing document.\n\n\n```json\n// Order with extended customer reference\n{\n \"_id\": \"order_123\",\n \"customer_id\": \"customer_456\",\n \"customer_name\": \"John Doe\",\n \"customer_email\": \"john@example.com\",\n \"items\": [...],\n \"total\": 1057\n}\n```\n\n\n#### Benefits\n\n- Avoids joins for common queries\n- Canonical data still in referenced collection\n- Trade consistency for read performance\n\n**Caveat:** Must update copies when source changes (eventual consistency).\n\n**Use case:** Order history display, activity feeds, denormalized views.\n\n---\n\n# 4. Shard Key Selection Strategies\n\nThe shard key is the most consequential decision in a sharded MongoDB deployment. It determines how data distributes across shards, which queries can target specific shards, and whether your cluster remains balanced under load. \n\nUnlike many schema decisions, the shard key is expensive to change. Modern MongoDB supports resharding and, in some cases, shard key value updates, but these are operationally heavy changes. Getting this decision wrong can mean living with performance problems for a long time or undertaking a careful resharding project.\n\n### 4.1 Shard Key Requirements\n\nA good shard key should have:\n\n**High cardinality:** Many distinct values to distribute data across shards.\n\n**Even distribution:** Values appear with similar frequency to avoid hot spots.\n\n**Query isolation:** Common queries include the shard key to target specific shards.\n\n**Write distribution:** Writes spread across shards rather than concentrating on one.\n\n### 4.2 Common Shard Key Strategies\n\n#### 1. Hashed Shard Key\n\nMongoDB applies a hash function to the shard key value before assigning a chunk range, which spreads documents across shards regardless of the original key pattern:\n\n\n```javascript\nsh.shardCollection(\"app.users\", { user_id: \"hashed\" })\n```\n\n\n\n```mermaid\nflowchart LR\n subgraph Input[\"User IDs\"]\n A[user_1]:::primary\n B[user_2]:::primary\n C[user_3]:::primary\n end\n\n subgraph Hash[\"Hash Function\"]\n H[hash]:::orange\n end\n\n subgraph Shards[\"Shards\"]\n S1[Shard 1]:::green\n S2[Shard 2]:::green\n S3[Shard 3]:::green\n end\n\n A --> H\n B --> H\n C --> H\n H --> S1\n H --> S2\n H --> S3\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\n\n### Pros\n\n- Even distribution regardless of key pattern\n- Good for monotonically increasing keys (ObjectId, timestamp)\n\n### Cons\n\n- Range queries become scatter-gather (must hit all shards)\n- Cannot use targeted queries for ranges\n\n\n**Best for:** Write-heavy workloads with point queries.\n\n#### 2. Ranged Shard Key\n\nA ranged key preserves sort order, so documents with adjacent key values land on the same shard and range queries stay targeted. The following example shards on `customer_id` so all orders for a given customer are co-located:\n\n\n```javascript\nsh.shardCollection(\"app.orders\", { customer_id: 1 })\n```\n\n\n\n### Pros\n\n- Range queries on shard key are targeted\n- Related data stays together\n\n### Cons\n\n- Can create hot spots if distribution is uneven\n- Monotonically increasing keys cause \"hot shard\" at the end\n\n\n**Best for:** Read-heavy workloads with range queries.\n\n#### 3. Compound Shard Key\n\nA compound key combines a high-cardinality field for distribution with a second field for ordering within a shard, giving targeted routing for prefix queries while maintaining time order inside each tenant's data:\n\n\n```javascript\nsh.shardCollection(\"app.events\", { tenant_id: 1, timestamp: 1 })\n```\n\n\n\n### Pros\n\n- Combines distribution (tenant_id) with ordering (timestamp)\n- Queries on prefix are targeted\n\n### Cons\n\n- More complex to design\n- Must include leading fields in queries\n\n\n**Best for:** Multi-tenant applications with time-based data.\n\n### 4.3 Shard Key Anti-Patterns\n\n\n| Anti-Pattern | Problem | Solution |\n|--------------|---------|----------|\n| Low cardinality | Few values limit max shards | Use compound key or hash |\n| Monotonically increasing | All writes hit one shard | Use hashed key or add random prefix |\n| Highly mutable | Shard key updates are restricted and operationally expensive | Choose a stable field |\n| Query mismatch | Common queries do not include shard key | Redesign key to match access patterns |\n\n\n### 4.4 Shard Key Example: E-commerce Orders\n\n#### Requirements\n\n- Query orders by customer\n- Query orders by date range\n- High write volume during sales\n\n#### Option 1: customer_id (ranged)\n\nSharding on `customer_id` with a ranged strategy places all of a customer's orders on one shard, making per-customer reads efficient but causing scatter-gather for time-range queries:\n\n\n```javascript\nsh.shardCollection(\"orders\", { customer_id: 1 })\n```\n\n\n- Good for: \"Get all orders for customer X\"\n- Bad for: \"Get all orders from last hour\" (scatter-gather)\n\n#### Option 2: order_date (ranged)\n\nSharding by `order_date` supports efficient date-range queries, but a monotonically increasing timestamp concentrates every new insert onto the most recent shard, creating a write hot spot:\n\n\n```javascript\nsh.shardCollection(\"orders\", { order_date: 1 })\n```\n\n\n- Good for: \"Get orders from date range\"\n- Bad for: Hot shard during active hours\n\n#### Option 3: Compound key (recommended)\n\nHashing `customer_id` breaks the monotonic growth problem while the second field `order_date` preserves per-customer ordering within a shard, balancing write distribution against query efficiency:\n\n\n```javascript\nsh.shardCollection(\"orders\", { customer_id: \"hashed\", order_date: 1 })\n```\n\n\n- Distributes writes across shards (hashed customer_id)\n- Supports customer queries (targeted)\n- Date queries are scatter-gather (acceptable trade-off)\n\n---\n\n# 5. Indexing for Performance\n\nSchema design determines what data you store together. Indexing determines how fast you can find it. Without indexes, MongoDB performs collection scans, reading every document to find matches. This works fine for hundreds of documents but becomes catastrophic at scale. \n\nA query that takes 5 milliseconds with a proper index might take 5 seconds without one. Understanding index types, compound index ordering, and the trade-off between read performance and write overhead is essential for building performant MongoDB applications.\n\n### 5.1 Index Types and When to Use Them\n\n#### Single Field Index\n\nA single-field index on a frequently queried field eliminates collection scans for simple equality and range filters. This example indexes the `email` field in ascending order:\n\n\n```javascript\ndb.users.createIndex({ email: 1 })\n```\n\n\nUse for: Simple queries on one field.\n\n#### Compound Index\n\nA compound index covers queries that filter and sort on multiple fields. Field order matters, because MongoDB can only use the index from left to right:\n\n\n```javascript\ndb.orders.createIndex({ customer_id: 1, order_date: -1 })\n```\n\n\nUse for: Queries filtering/sorting on multiple fields. Order matters.\n\n#### Multikey Index (Arrays)\n\nWhen a field holds an array, MongoDB creates a multikey index by indexing each element individually, making membership queries efficient without scanning every document:\n\n\n```javascript\ndb.products.createIndex({ tags: 1 })\n```\n\n\nUse for: Searching within array fields.\n\n#### Text Index\n\nA text index tokenizes string fields and supports `$text` search queries, including stemming and stop-word filtering. Multiple fields can share a single text index, as shown here for articles:\n\n\n```javascript\ndb.articles.createIndex({ title: \"text\", content: \"text\" })\n```\n\n\nUse for: Full-text search.\n\n#### Geospatial Index\n\nA `2dsphere` index stores GeoJSON coordinates in a way that supports proximity searches, bounding box queries, and intersection operators on spherical geometry:\n\n\n```javascript\ndb.places.createIndex({ location: \"2dsphere\" })\n```\n\n\nUse for: Location-based queries.\n\n#### TTL Index\n\nA TTL index tells MongoDB to automatically delete documents once a date field passes a specified age, removing the need for a separate cleanup job. This example expires session documents one hour after creation:\n\n\n```javascript\ndb.sessions.createIndex({ createdAt: 1 }, { expireAfterSeconds: 3600 })\n```\n\n\nUse for: Automatic document expiration.\n\n### 5.2 Compound Index Order (ESR Rule)\n\nFor compound indexes, follow the **Equality, Sort, Range** order:\n\n\n```javascript\n// Query\ndb.orders.find({\n status: \"shipped\", // Equality\n total: { $gt: 100 } // Range\n}).sort({ order_date: -1 }) // Sort\n\n// Optimal index\ndb.orders.createIndex({\n status: 1, // E: Equality first\n order_date: -1, // S: Sort second\n total: 1 // R: Range last\n})\n```\n\n\n**Why this order?**\n\n1. **Equality** narrows down candidates immediately\n2. **Sort** uses index order (no in-memory sort)\n3. **Range** filters remaining documents\n\n### 5.3 Covered Queries\n\nA **covered query** returns results directly from the index without accessing documents.\n\n\n```javascript\n// Index on name and email\ndb.users.createIndex({ name: 1, email: 1 })\n\n// Covered query (only returns indexed fields)\ndb.users.find(\n { name: \"John\" },\n { name: 1, email: 1, _id: 0 } // Projection must exclude _id\n)\n\n// Result comes entirely from index - very fast!\n```\n\n\n### 5.4 Index Intersection\n\nMongoDB can combine multiple indexes for a single query:\n\n\n```javascript\n// Indexes\ndb.products.createIndex({ category: 1 })\ndb.products.createIndex({ price: 1 })\n\n// Query uses both indexes\ndb.products.find({ category: \"electronics\", price: { $lt: 500 } })\n```\n\n\nHowever, a compound index is usually more efficient than intersection.\n\n### 5.5 Index Strategy Guidelines\n\n\n| Scenario | Strategy |\n|----------|----------|\n| High-frequency query | Dedicated compound index |\n| Ad-hoc queries | Multiple single-field indexes |\n| Text search | Text index with weights |\n| Geospatial | 2dsphere index |\n| Time-based expiration | TTL index |\n| Unique constraint | Unique index |\n\n\n\n```mermaid\nflowchart TD\n A[Analyze query patterns]:::primary\n A --> B[Identify high-frequency queries]:::primary\n B --> C[Create compound indexes for each]:::green\n C --> D[Use explain to verify]:::orange\n D --> E{Index used?}:::yellow\n E -->|No| F[Adjust index or query]:::red\n E -->|Yes| G{Performance OK?}:::yellow\n G -->|No| F\n G -->|Yes| H[Monitor and iterate]:::green\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n classDef yellow fill:#ffd43b,stroke:#000,color:#000\n```\n\n\n\n> **TIP**\n>\n> **Design note:** Indexes trade write cost for read speed. A product catalog with frequent searches and infrequent updates can afford compound indexes for major query patterns. An IoT ingestion workload should keep indexes minimal, perhaps only `sensor_id` and `timestamp`, to avoid write bottlenecks.\n>\n> Each index speeds up some reads but slows down writes and consumes memory/storage. Treat indexes as part of the write path, not just a read optimization.\n\n\n---\n\n# 6. Read and Write Concerns\n\nMongoDB lets you choose the consistency-latency trade-off per operation. Focus on three knobs:\n\n- **Write concern:** how many replica-set members must acknowledge a write.\n- **Read concern:** what consistency guarantee a read requires.\n- **Read preference:** whether reads go to the primary or can go to secondaries.\n\n### 6.1 Write Concern\n\n\n| Level | Meaning | Design takeaway |\n|-------|---------|-----------------|\n| `w: 1` | Primary acknowledges | Fast, but a just-acknowledged write can be lost during failover |\n| `w: \"majority\"` | Majority acknowledges | Better durability across failover, with higher latency |\n| `w: 0` | No acknowledgment | Rarely appropriate for user-visible writes |\n\n\nFor most correctness-sensitive operations, use `w: \"majority\"` so acknowledged writes are less likely to disappear after primary failover.\n\n### 6.2 Read Concern and Read Preference\n\n\n| Requirement | Reasonable choice | Trade-off |\n|-------------|-------------------|-----------|\n| Read-your-writes | Read from `primary` | Higher primary load |\n| Survive failover with consistent reads | `majority` read concern + primary reads | More latency than local reads |\n| Scale stale-tolerant reads | `secondaryPreferred` | May return older data |\n| Strongest single-document freshness | `linearizable` read concern | Highest latency; use only when required |\n\n\nThe practical rule is simple: keep critical user flows on primary reads with majority writes; use secondary reads for dashboards, analytics, feeds, or other paths that can tolerate staleness.\n\n---\n\n# 7. Transactions and Consistency\n\nMongoDB supports multi-document ACID transactions, but they should not be the default modeling strategy. The first design question is whether related data can live in one document, because single-document updates are atomic.\n\n### 7.1 Model for Single-Document Atomicity\n\nIf an invariant naturally belongs inside one aggregate, keep it in one document. For example, updating an order status and appending an order event can often be one atomic document update. This avoids distributed coordination and usually scales better than transactions.\n\n### 7.2 When Transactions Are Worth Mentioning\n\nUse multi-document transactions when a business invariant crosses document boundaries and eventual consistency is not acceptable.\n\n\n| Use transactions for | Prefer another approach when |\n|----------------------|------------------------------|\n| Money movement between accounts | A single document can own the invariant |\n| Inventory reservation with strict correctness | Idempotent async processing is acceptable |\n| Updating multiple entities that must commit together | Throughput is more important than immediate consistency |\n| Enforcing application-level referential integrity | The relationship is read-heavy and can be denormalized |\n\n\nThe trade-off to say out loud: transactions add latency, increase contention, and become more expensive when they cross shards. A strong answer explains why the data model avoids them for the common path and reserves them for true invariants.\n\n---\n\n# 8. Change Streams for Event-Driven Features\n\nChange streams let applications react to MongoDB changes without polling. They are useful when MongoDB is the source of truth and downstream systems need updates, such as search indexing, cache invalidation, notifications, or dashboard refreshes.\n\n### 8.1 Reliability Notes\n\nThe core flow is:\n\n\n```javascript\nMongoDB write -> oplog entry -> change stream consumer -> downstream update\n```\n\n\nTwo reliability details matter: consumers should resume from tokens after restarts, and handlers should be idempotent because retries can happen. Change streams are not always a complete replacement for a durable event bus or outbox pattern; if events are a core contract between services, a queue/log such as Kafka may still be the better boundary.\n\n### 8.2 Change Streams vs Polling\n\n\n| Aspect | Change Streams | Polling |\n|--------|----------------|---------|\n| Latency | Near real-time | Depends on polling interval |\n| Efficiency | Push-based | Repeated queries |\n| Resume | Built-in resume tokens | Application-managed cursor/checkpoint |\n| Best fit | Reactive features and sync pipelines | Simple low-volume jobs |\n\n\n---\n\n# 9. MongoDB vs Other Databases\n\nUse this comparison to keep the choice tied to data shape and access patterns:\n\n\n| Alternative | Prefer MongoDB when... | Prefer the alternative when... |\n|-------------|------------------------|--------------------------------|\n| PostgreSQL | Data is document-shaped and schema flexibility matters | Joins, relational integrity, or heavy transactions dominate |\n| DynamoDB | You need richer queries, aggregations, or flexible access patterns | Access patterns are fixed and managed scale matters most |\n| Cassandra | You need general document storage with richer query support | Writes are extreme and availability matters more than query flexibility |\n| Elasticsearch | MongoDB is the source data store and search is secondary | Search relevance, faceting, or log exploration is the core requirement |\n\n\n---\n\n# Summary\n\nUse MongoDB when the data is document-shaped, access patterns are clear, and schema flexibility is valuable. The main risks are over-normalizing, unbounded documents, poor shard keys, and too many secondary indexes on write-heavy collections.\n\nAnchor the answer on data modeling first: embed what is read together, reference shared or unbounded data, choose shard keys that spread load, and tune read/write concern based on the consistency requirement.\n\n---\n\n# Quiz","pageType":"system-design-interviews"}

Get Premium