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

Challenge - 5 Problems

🧠 Conceptual

intermediate

Choosing the right schema for frequent writes

You have a MongoDB collection that receives thousands of writes per second. Which schema design approach helps reduce write conflicts and improves write performance?

A Use a schema with small, flat documents and avoid embedding large arrays to reduce document size and locking.

B Use a normalized schema with references to separate documents to avoid large document sizes.

C Embed all related data in a single document to minimize the number of writes.

D Store all data in a single large document to reduce the number of documents and simplify queries.

💡 Hint

Think about how MongoDB locks documents during writes and how document size affects write speed.

Small, flat documents reduce the chance of write conflicts and improve write throughput because MongoDB locks at the document level. Embedding large arrays or storing all data in one document can cause large document sizes and slow writes.

❓ query_result

intermediate

Result of updating embedded documents in a write-heavy schema

Consider a MongoDB collection where user profiles embed an array of login timestamps. You run this update:

db.users.updateOne({ _id: 1 }, { $push: { logins: ISODate() } })

What is the expected effect on write performance if the logins array grows very large?

A Write performance degrades because the entire document must be rewritten when the array grows large.

B Write performance remains stable because MongoDB only updates the array element.

C Write performance improves because the array is indexed automatically.

D Write performance is unaffected because MongoDB uses row-level locking.

💡 Hint

Consider how MongoDB handles document updates and the impact of large arrays on document size.

MongoDB rewrites the entire document on update. Large arrays increase document size, causing slower writes and more disk I/O.

📝 Syntax

advanced

Identify the correct schema design for high write throughput

Which MongoDB schema design below best supports a write-heavy workload where each write is a new event that must be stored quickly?

A Store all events in a single document with an ever-growing array of events.

B Embed events inside user documents and update the entire user document on each event.

C Use a capped collection with a fixed size to store events, overwriting old events automatically.

D Store each event as a separate small document in a collection with an index on the event timestamp.

💡 Hint

Think about how document size and indexing affect write speed and storage.

Storing each event as a separate small document allows fast inserts and avoids large document rewrites. Indexing on timestamp supports efficient queries.

🔧 Debug

advanced

Why does this write-heavy schema cause slow writes?

A MongoDB collection stores user activity logs embedded inside user documents as arrays. Over time, writes slow down significantly. What is the most likely cause?

A MongoDB does not support arrays inside documents, causing errors.

B The arrays grow too large, causing document rewrites and increased disk I/O.

C The collection lacks an index on the user ID field.

D The server is running out of RAM due to too many indexes.

💡 Hint

Consider how MongoDB handles document updates and the impact of large embedded arrays.

Large arrays cause the entire document to be rewritten on each update, slowing down writes as document size grows.

🧠 Conceptual

expert

Optimizing schema for write-heavy workloads with sharding

You have a MongoDB cluster with sharding enabled to handle a write-heavy workload. Which shard key choice best supports even write distribution and avoids write hotspots?

A Use a monotonically increasing field like a timestamp as the shard key.

B Use a hashed value of a frequently updated field as the shard key.

C Use a compound shard key combining user ID and a random suffix.

D Use a constant value as the shard key for all documents.

💡 Hint

Think about how shard keys affect data distribution and write load balancing.

A compound shard key with a random suffix spreads writes across shards evenly, avoiding hotspots caused by monotonically increasing keys.