Schema design for read-heavy workloads in MongoDB - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why embed documents in MongoDB for read-heavy workloads?

In MongoDB, when designing a schema for a read-heavy application, why is embedding related data inside a single document often preferred over referencing separate documents?

A Embedding reduces the number of queries needed to fetch related data, improving read performance.

B Embedding increases the size of each document, which slows down reads significantly.

C Embedding forces MongoDB to create multiple indexes, which hurts read speed.

D Embedding requires more disk space, so it is avoided in read-heavy workloads.

💡 Hint

Think about how many database calls are needed to get all related data.

Embedding related data in one document means MongoDB can retrieve all needed information in a single read operation, which is faster for read-heavy workloads.

❓ query_result

intermediate

Result of a MongoDB query with embedded documents

Given a collection users where each user document embeds an array of orders, what will be the output of this query?

db.users.find({"orders.status": "shipped"}, {name: 1, orders: 1})

Assuming the collection has:

{ "name": "Alice", "orders": [{"id": 1, "status": "shipped"}, {"id": 2, "status": "pending"}] }
{ "name": "Bob", "orders": [{"id": 3, "status": "pending"}] }

A [{ "name": "Alice", "orders": [{"id": 1, "status": "shipped"}] }]

B []

C [{ "name": "Bob", "orders": [{"id": 3, "status": "pending"}] }]

D [{ "name": "Alice", "orders": [{"id": 1, "status": "shipped"}, {"id": 2, "status": "pending"}] }]

💡 Hint

Remember that MongoDB returns the whole document if any embedded document matches the query.

The query matches users with any order having status 'shipped'. It returns the full user document with all orders, not just the matching orders.

📝 Syntax

advanced

Correct schema design for fast reads with large arrays

Which MongoDB schema design is best for a read-heavy workload where each user has thousands of comments, and you want to quickly fetch the latest 10 comments?

A Embed all comments inside the user document in a single array.

B Store comments in a separate collection with a user_id field and index on user_id and timestamp.

C Embed comments in multiple arrays inside the user document, splitting by year.

D Store comments in a separate collection without any indexes.

💡 Hint

Think about document size limits and efficient querying.

Embedding thousands of comments in one document risks exceeding size limits and slows reads. Storing comments separately with proper indexes allows fast queries for latest comments.

❓ optimization

advanced

Optimizing read performance with indexes in MongoDB

You have a collection products with fields category, price, and rating. Your app frequently queries products by category and sorts by price ascending. Which index will optimize these queries best?

A Create a compound index on { price: 1, category: 1 }

B Create a single index on price only

C Create a compound index on { category: 1, price: 1 }

D Create a single index on category only

💡 Hint

Consider the order of fields in compound indexes for filtering and sorting.

A compound index on category then price supports filtering by category and sorting by price efficiently.

🔧 Debug

expert

Why does this MongoDB query run slowly on a read-heavy workload?

Consider this query on a large orders collection:

db.orders.find({ status: "completed" }).sort({ orderDate: -1 }).limit(5)

The query is slow despite indexes on status and orderDate separately. What is the main reason?

A MongoDB cannot use two separate indexes efficiently for filtering and sorting; a compound index is needed.

B The limit(5) clause causes MongoDB to scan the entire collection.

C Indexes on individual fields always slow down queries with sort.

D The query syntax is invalid and causes a full collection scan.

💡 Hint

Think about how MongoDB uses indexes for filtering and sorting together.

MongoDB can only use one index efficiently per query stage. Separate indexes on status and orderDate don't help sorting after filtering. A compound index on {status: 1, orderDate: -1} is needed.

Practice

1. Which schema design approach is best for read-heavy workloads in MongoDB?

easy

A. Embed related data in the same document to reduce read operations

B. Use references for all data to keep documents small

C. Normalize data like in relational databases

D. Store all data in separate collections regardless of usage

Solution

1. Step 1: Understand read-heavy workload needs

   Read-heavy workloads benefit from fewer queries and faster data retrieval.

2. Step 2: Choose schema design for fast reads

   Embedding related data in one document reduces the need for multiple queries, speeding up reads.

3. Final Answer:

   Embed related data in the same document to reduce read operations -> Option A

4. Quick Check:

   Embedding = faster reads [OK]

Hint: Embed related data for fast reads in read-heavy apps [OK]

Common Mistakes:

• Choosing referencing for all data slows reads
• Normalizing like SQL increases read complexity
• Separating all data causes many queries

2. Which of the following is the correct way to embed an array of comments inside a blog post document in MongoDB?

easy

A. { title: 'Post', comments: [{ user: 'Alice', text: 'Nice!' }, { user: 'Bob', text: 'Great!' }] }

B. { title: 'Post', comments: 'user: Alice, text: Nice!' }

C. { title: 'Post', comments: { user: 'Alice', text: 'Nice!' } }

D. { title: 'Post', comments: ['user: Alice', 'text: Nice!'] }

Solution

1. Step 1: Identify correct array embedding syntax

   Embedding an array of subdocuments requires an array of objects inside the field.

2. Step 2: Check each option's structure

   { title: 'Post', comments: [{ user: 'Alice', text: 'Nice!' }, { user: 'Bob', text: 'Great!' }] } correctly uses an array of objects for comments; others use incorrect types or formats.

3. Final Answer:

   { title: 'Post', comments: [{ user: 'Alice', text: 'Nice!' }, { user: 'Bob', text: 'Great!' }] } -> Option A

4. Quick Check:

   Array of objects = correct embedding [OK]

Hint: Use array of objects to embed multiple related items [OK]

Common Mistakes:

• Using string instead of array for multiple comments
• Embedding a single object instead of an array
• Using array of strings instead of objects

3. Given this MongoDB document for a product with embedded reviews:

{ _id: 1, name: 'Gadget', reviews: [{ user: 'Ann', rating: 5 }, { user: 'Ben', rating: 4 }] }

What will be the result of this query?

db.products.findOne({ _id: 1 }, { name: 1, 'reviews.rating': 1 })

medium

A. { name: 'Gadget', reviews: [{ rating: 5 }, { rating: 4 }] }

B. { _id: 1, name: 'Gadget', reviews: [{ rating: 5 }, { rating: 4 }] }

C. { _id: 1, name: 'Gadget' }

D. { _id: 1, name: 'Gadget', reviews: [{ user: 'Ann', rating: 5 }, { user: 'Ben', rating: 4 }] }

Solution

1. Step 1: Understand projection with dot notation

   Using 'reviews.rating': 1 includes only the rating field inside each review subdocument.

2. Step 2: Analyze returned fields

   The query returns _id, name, and reviews with only rating fields (user excluded).

3. Final Answer:

   { _id: 1, name: 'Gadget', reviews: [{ rating: 5 }, { rating: 4 }] } -> Option B

4. Quick Check:

   Projection with dot notation = filtered subfields [OK]

Hint: Use dot notation in projection to include subfields only [OK]

Common Mistakes:

• Expecting full subdocuments when projecting subfields
• Forgetting _id is included by default
• Assuming projection excludes _id without explicit exclusion

4. You designed a schema embedding user addresses inside user documents, but queries on addresses are slow. What is the likely problem?

medium

A. MongoDB does not support embedding arrays

B. Embedding always makes queries slower

C. You must store addresses in a separate database

D. Addresses should be referenced separately if they are large or updated often

Solution

1. Step 1: Identify embedding drawbacks

   Embedding large or frequently changing data can cause large documents and slow updates or queries.

2. Step 2: Choose referencing for large or mutable data

   Referencing addresses separately keeps user documents small and improves query speed on addresses.

3. Final Answer:

   Addresses should be referenced separately if they are large or updated often -> Option D

4. Quick Check:

   Large mutable data = use referencing [OK]

Hint: Reference large or changing data to keep documents small [OK]

Common Mistakes:

• Assuming embedding always improves speed
• Thinking MongoDB disallows embedding arrays
• Believing separate databases are needed for performance

5. You have a read-heavy app showing user profiles with many posts. Posts change often, but profiles rarely do. How should you design the schema for fast reads?

hard

A. Embed user profile data inside each post document

B. Embed posts inside user profiles despite frequent changes

C. Store user profiles and posts in separate collections, referencing posts from profiles

D. Duplicate posts data inside profiles and update both on changes

Solution

1. Step 1: Analyze data change frequency

   Posts change often; embedding them inside profiles would cause large documents and frequent updates.

2. Step 2: Choose referencing for frequently changing large data

   Storing posts separately and referencing them keeps profiles small and reads fast.

3. Step 3: Avoid data duplication to prevent sync issues

   Duplicating posts in profiles causes update complexity and inconsistency risks.

4. Final Answer:

   Store user profiles and posts in separate collections, referencing posts from profiles -> Option C

5. Quick Check:

   Frequent changes = referencing large data [OK]

Hint: Reference frequently changing data, embed stable data [OK]

Common Mistakes:

• Embedding frequently changing posts inside profiles
• Duplicating data causing sync problems
• Embedding profiles inside posts which is illogical