Data Modeling practice questions

The total number of collections currently in the database.

Why it fails: The number of collections is not a primary factor in choosing between embedding and referencing. MongoDB handles many collections efficiently. The decision should be based on data structure and application access requirements, not an arbitrary count of collection objects, which does not reflect the underlying performance characteristics.

The color-coding of the application code documentation.

Why it fails: Documentation style has zero impact on database performance or modeling. Decisions must be based on technical constraints, performance requirements, and scalability needs. Focusing on non-technical factors leads to poor design choices that do not leverage the strengths of the MongoDB document model effectively in production environments.

Embedding all data from a related collection to ensure maximum speed.

Why it fails: Embedding all data is simply the 'Embedding' pattern, not the 'Extended Reference' pattern. Extended Reference is specifically about embedding *some* data, usually read-only, while keeping the rest in a separate collection to maintain data integrity and support complex updates without massive data duplication issues across the entire database.

Referencing a document by its ID and performing a $lookup for all queries.

Why it fails: This describes standard Referencing. Extended Reference is an optimization on top of standard referencing, where you strategically embed small, stable bits of information to avoid the $lookup entirely for the most frequent read paths, thereby improving application responsiveness while keeping the bulk of the data in the separate collection.

Adding a secondary index on all fields to speed up queries.

Why it fails: This is just indexing, which is not a data modeling pattern. Extended Reference is a structural strategy for document design that focuses on which fields to include in a document. Indexing is a separate performance optimization layer that does not address the fundamental design of your document schema.

When the data is only used by one specific parent document.

Why it fails: If data is only used by one parent document, embedding is usually the best choice. This ensures the data is always available when the parent is read, reducing the need for lookups and keeping the related information encapsulated, which is a key advantage of the document model over relational tables.

When you need to keep the total document size small.

Why it fails: Embedding can actually help keep total document size small if the related data is small and accessed together. The issue is not the size itself, but the *growth* of that size. If the data remains small and static, embedding is perfectly acceptable and often improves overall system throughput and read latency.

When you need to use an aggregation pipeline for analysis.

Why it fails: MongoDB aggregation pipelines work excellently with embedded data. You can unwind arrays, project fields, and group embedded data just as effectively as you can with referenced data. Aggregation is not a reason to avoid embedding; it is a powerful tool to process both embedded and referenced data structures effectively.

The Bucket Pattern.

Why it fails: The Bucket Pattern is specifically for time-series data or high-frequency log events. It is designed to group small, related readings into a single document to save space and index overhead. It is not designed for storing general, frequently accessed information that is used across multiple query types in your application.

The Attribute Pattern.

Why it fails: The Attribute Pattern is for heterogeneous data where the fields vary across documents. It is not about duplicating shared data for performance; it is about providing a standardized schema for variable fields. Using it for shared, rarely-changing data is inappropriate and would add unnecessary indexing complexity to your database design.

The Polymorphic Pattern.

Why it fails: The Polymorphic Pattern is for documents that share a common structure but have slight variations. It is used to group different document types in one collection. It is not an optimization for shared data access patterns and would not help with the performance of reading commonly used, static information.

A user profile that needs to link to millions of social media posts.

Why it fails: Referencing is mandatory here because embedding millions of posts would immediately exceed the 16MB document limit. When a relationship is one-to-many with an unbounded growth potential, the only viable strategy is to store the reference IDs in the parent document or the parent ID in the child.

A user document that needs to store an unbounded history of login timestamps.

Why it fails: Storing an unbounded array of login timestamps will eventually lead to document bloat and performance issues. As the array grows, the document size increases, eventually hitting the limit or causing slow write operations. In this case, an external collection with references is necessary for sustainable long-term growth.

A catalog where items frequently change and are shared across many vendors.

Why it fails: When data is highly dynamic and shared across multiple entities, embedding leads to significant data redundancy and update anomalies. If a shared catalog item changes, you would have to update every document where it is embedded, which is inefficient and difficult to maintain compared to a referenced collection.

The specific version of the MongoDB server in use.

Why it fails: While MongoDB versions introduce new features like $lookup, the fundamental principles of data modeling remain consistent across versions. The decision to embed or reference is based on data relationship and access patterns rather than the specific software version installed on the cluster, making this a secondary consideration.

The color scheme of the application interface.

Why it fails: The user interface color scheme has absolutely no impact on the database schema or data modeling decisions. Choosing a model should be strictly based on performance requirements, data relationship structures, and the physical constraints of the MongoDB BSON document format, not on any aesthetic or UI design factors.

Increase the collection's padding factor to allow for document growth.

Why it fails: Padding factor is a legacy concept and no longer directly controlled in modern WiredTiger storage engine configurations. Even if it were, simply allocating more space does not solve the long-term problem of unbounded document growth, which eventually leads to performance degradation and memory pressure during frequent collection scans.

Implement a sharded cluster to distribute the user documents across nodes.

Why it fails: Sharding distributes the load but does not solve the underlying issue of oversized, frequently updated documents on a single shard. If a document continues to grow, it will eventually cause the same performance problems on the shard where it resides, regardless of how many shards are in the cluster.

Use the $push operator with $each to batch all updates together.

Why it fails: Batching updates with $push does not stop the document from growing. Even with batching, the document will eventually reach a size that causes performance issues and potentially exceeds the 16MB document limit. This is a stop-gap measure that does not address the fundamental architectural flaw of an unbounded embedded array.

Keep the daily array but add a multikey index on `trades.symbol` and a separate index on `trades.price`.

Why it fails: Multikey indexes on array fields can be inefficient for range queries across multiple array elements, and separate indexes on `trades.symbol` and `trades.price` do not support combined filtering by symbol and date range. This approach also leaves the array unbounded, risking document growth and performance degradation as trades accumulate.

Embed all trades for the entire year in a single document and create a single index on the `trades` array.

Why it fails: Embedding a year's worth of trades in one document will likely exceed the 16MB BSON document limit and cause severe write contention. A single index on the entire array cannot efficiently serve queries that filter by symbol and date range because it lacks the granularity to isolate specific elements, leading to full array scans.

Normalize trades into a separate collection and use `$lookup` to join them at query time without any indexes.

Why it fails: Using `$lookup` without indexes on the foreign field forces a collection scan for each join, which is extremely slow at scale. While normalization can be valid, omitting indexes on the join key defeats the purpose and does not address the need for efficient symbol and date range filtering. This design would not meet the performance requirements.

Use the Bucket Pattern by grouping transactions into buckets based on account_id and time range.

Why it fails: The Bucket Pattern is designed for time-series data to reduce the number of documents and indexes by grouping many measurements into a single document. However, in this scenario, each transaction is an individual event that may need to be queried or updated independently. Bucketing would complicate queries that filter on specific metadata fields and could make updates to individual transactions more difficult.

Use the Polymorphic Pattern by storing all transaction types in a single collection with a 'type' field and a flexible metadata subdocument.

Why it fails: The Polymorphic Pattern is useful for storing different document shapes in one collection, but it does not inherently optimize index size or query performance for the specific filters on account_id and timestamp. Indexes would still need to cover the metadata fields, which can be large and variable, potentially leading to inefficient indexes and increased storage.

Use the Extended Reference Pattern by embedding frequently accessed account information into each transaction document.

Why it fails: The Extended Reference Pattern is used to avoid joins by embedding a subset of fields from a related document. Here, the issue is not about joining with another collection but about handling variable metadata fields within the same document. This pattern does not address the need to optimize queries and indexes on those metadata fields, so it is not the best fit.

Polymorphic Pattern: store different types of financial instruments (stocks, bonds, options) in the same collection with varying fields to simplify application logic.

Why it fails: The Polymorphic Pattern is used when documents in a collection have different structures, such as different types of financial instruments. However, this scenario focuses on a single type (stocks) and the challenge of managing a growing array of daily prices. The Polymorphic Pattern does not address document size or query performance for time-series data, so it is not relevant here.

Computed Pattern: precompute and store the 30-day moving average and other aggregates in each stock document to avoid runtime calculations.

Why it fails: While the Computed Pattern can improve read performance by precomputing aggregates, it is not the primary solution for managing the growing array of daily prices. The main issue is the unbounded growth of the array and the need to efficiently query recent data. The Computed Pattern would still require reading the raw data for other queries, and it does not address the document size or query efficiency for retrieving the last 30 days.

Extended Reference Pattern: embed frequently accessed fields from related collections into the stock document to avoid joins.

Why it fails: The Extended Reference Pattern is used to duplicate a few fields from a related collection to avoid frequent joins. In this scenario, there is no mention of related collections or joins; the data is self-contained within the stock document. Therefore, this pattern does not solve the problem of a growing array or improve query performance for time-series data.

Store each reading as its own document and rely on a compound index on device and timestamp.

Why it fails: One document per reading abandons the Bucket pattern and multiplies document count, index entries, and write operations. While a compound index does support latest-reading queries, the storage and write amplification are exactly what bucketing was meant to avoid. The scenario already chose hourly buckets, so reverting is counterproductive.

Store readings in a map keyed by a random identifier so writes distribute evenly, and scan values to find the newest.

Why it fails: Random keys remove the ordering that makes the newest reading easy to locate, forcing a scan of all values on every query. Even write distribution is already achieved by bucketing on device and hour. This choice trades query efficiency for a write benefit that is not needed here.

Use a separate 'latest' collection updated on every write, and query only that collection for the newest reading.

Why it fails: Maintaining a separate latest collection adds a second write on every reading and introduces consistency risk if the two writes diverge. The bucket already contains the newest reading, so duplicating it is unnecessary. This approach is a caching workaround, not a modeling improvement, and it complicates recovery.

Keep only customerId in the account and resolve the customer with a $lookup on every account read.

Why it fails: A $lookup on every read adds a join stage that fetches the customer document each time, increasing latency and load on the customer collection for a hot read path. Since almost every account query needs the same two fields, paying join cost repeatedly is wasteful when those fields rarely change and could be cached in the account itself.

Embed the customer document in the account and stop updating the customer collection, treating the account copy as the source of truth.

Why it fails: Making each account's embedded copy authoritative creates multiple competing sources of truth for the same customer, so different accounts can disagree about KYC status. This breaks the consistency requirement and makes customer-level reporting unreliable. It also prevents a single canonical customer record, which the application clearly needs for updates.

Embed the entire customer document inside each account document.

Why it fails: Embedding the full customer record duplicates frequently changing data into every account. When a customer's address or KYC status changes, all accounts referencing that customer must be updated, and without a transaction those updates can partially fail, leaving divergent copies. The scenario stresses frequent customer updates, which makes full embedding a consistency liability.

Embedding every possible attribute as a top-level field in the document.

Why it fails: Adding every possible attribute as a top-level field creates a sparse document with many null values. This leads to inefficient storage and complicates indexing because you would need many sparse indexes to cover all potential attributes, which does not scale well as the number of product categories grows over time.

Storing all product attributes as a single large JSON blob string.

Why it fails: Storing data as a raw string prevents MongoDB from performing server-side operations like filtering, sorting, or aggregation on specific attributes. You would be forced to pull the entire blob into application memory, destroying query performance and negating the benefit of using a document database for data access patterns.

Creating a separate collection for every individual product category.

Why it fails: Creating collection-per-category leads to massive administrative overhead and prevents cross-category aggregation. MongoDB performs best when similar data is stored within the same collection, allowing for shared indexes and efficient queries that span your entire product catalog, rather than requiring complex joins or multiple application-side merge operations.

Move all orders to a separate collection and reference them by ID in the user document.

Why it fails: This approach is the 'Extended Reference' pattern, not the 'Subset' pattern. While it avoids unbounded arrays, it requires an application-level join (two round trips to the database) for every read of the user profile, increasing latency compared to embedding the most recent data directly in the document.

Increase the maximum document size limit to accommodate the growing order array.

Why it fails: The 16MB document limit is a hard constraint designed to prevent performance degradation. Growing documents beyond this limit is not supported, and even approaching it causes significant overhead in memory allocation and disk I/O, which would severely degrade the performance of the entire database instance over time.

Use a capped collection for the orders array to automatically drop old orders.

Why it fails: Capped collections are fixed-size and behave like circular buffers, which is not suitable for persistent storage of user orders. Once the collection fills, old data is overwritten regardless of its importance, leading to data loss that would be unacceptable for an e-commerce order management system.

A blog post containing a list of comments that grows indefinitely.

Why it fails: Indefinitely growing lists lead to unbounded arrays, which eventually violate the 16MB document limit. This scenario is a classic example of when to use Referencing, where comments are stored in a separate collection linked by the parent document ID to ensure long-term scalability and document integrity.

A product catalog with millions of items linked to various categories.

Why it fails: In a many-to-many scenario, embedding would cause massive data duplication. If a category is renamed, you would need to update every single product document, leading to massive write amplification. Referencing is the superior choice here to maintain data consistency and reduce the overall storage footprint of the database.

A sensor data stream that stores millions of readings per hour.

Why it fails: Storing millions of sensor readings in a single document is physically impossible due to the 16MB limit. This requires high-frequency writes and time-series data modeling, which necessitates storing readings in separate documents or collections to ensure the database can handle the continuous volume of incoming sensor metrics.

Convert the tags array into a comma-separated string.

Why it fails: Storing tags as a string forces the engine to perform full-text searches or regex queries, which are significantly slower than multikey index lookups. You lose the ability to perform direct equality matches on specific tags, which negates the indexing benefits provided by MongoDB's native array support.

Create one index per tag value to ensure performance.

Why it fails: Creating an index for every possible tag value is inefficient and unmanageable as the number of unique tags grows. This would create an enormous number of indexes, consuming excessive memory and slowing down write operations significantly, as every document update would require updating every single tag-specific index.

Store tags in a separate collection and reference them using an object ID.

Why it fails: While this is a normalized approach, it is unnecessary for simple tag lookups. The overhead of performing a join or an application-side lookup for every tag query is much higher than simply utilizing a multikey index on the array, which is purpose-built for this exact use case.

Embed all follower IDs in an array within the user profile document.

Why it fails: This leads to an unbounded array. As the number of followers grows, the user document will inevitably grow until it hits the 16MB limit, causing application errors and requiring a difficult schema migration. This pattern does not scale for social media platforms with a large number of followers.

Use the Attribute Pattern to store each follower as a key-value pair.

Why it fails: The Attribute Pattern is for heterogeneous data fields, not for modeling large, homogeneous lists of relationships. Using it here would still force you to store all followers inside the user document, hitting the same document size limitations as a simple array, while adding unnecessary complexity to your queries.

Store the followers in a gridFS file to handle the large size.

Why it fails: GridFS is for storing large files, not for structured, queryable data like user relationships. Using GridFS for followers would make it impossible to query for specific followers or perform standard database operations, making the data largely inaccessible for the application's required social functionality and search features.

It allows for unlimited document growth without checking the 16MB limit.

Why it fails: Even with the bucket pattern, you must respect the 16MB document limit. The bucket size must be chosen so that the total data for the chosen time window comfortably fits within this size. Ignoring this limit would cause the application to crash once a bucket exceeds the maximum allowed document size.

It automatically converts all data to a binary format for faster storage.

Why it fails: The bucket pattern is a logical grouping strategy, not a storage-level format change. MongoDB already uses the BSON binary format for all data. The bucket pattern is about how you arrange your document relationships, not about changing how the database engine handles low-level data serialization or binary storage configurations.

It enables ACID transactions for non-related collections automatically.

Why it fails: ACID transactions are a feature of the MongoDB engine and have nothing to do with the Bucket pattern. The Bucket pattern is an optimization for data modeling. Transactions work across any document structure, so using the bucket pattern does not change or improve the capabilities of your transactional workflows.

It reduces the document size compared to sub-documents.

Why it fails: This structure actually increases the document size because you are repeating the 'k' and 'v' field names for every single attribute. The benefit is not storage savings, but index flexibility. You are trading a small amount of storage for a massive gain in query flexibility and indexing efficiency across the catalog.

It enforces strict schema validation for every attribute.

Why it fails: The Attribute Pattern is inherently flexible and does not enforce schema validation on the contents of the 'v' field. Schema validation is handled by JSON Schema validators in MongoDB. This pattern is about indexing efficiency and query capability, not about adding strict schema enforcement to your document structure or business logic.

It automatically performs joins between different products.

Why it fails: The Attribute Pattern does not facilitate joins. Joins are handled by $lookup. This pattern is designed to solve the problem of indexing diverse fields within a single collection, allowing for high-performance queries without complex operations or the need to normalize your data into multiple collections for different product attributes.

MongoDB automatically moves the overflow data to a new document.

Why it fails: MongoDB does not automatically move data between documents. If a write operation would push a document over 16MB, the entire write fails. The application is responsible for managing document size and ensuring that the schema is designed to prevent documents from reaching the hard limit defined by the BSON specification.

The engine automatically compresses the document to fit.

Why it fails: While WiredTiger uses compression for disk storage, the BSON limit applies to the uncompressed document in memory. Compression is a storage-level feature that does not allow you to bypass the 16MB limit, which is defined at the logical document level, not the physical disk storage level. You cannot exceed this limit.

The document is split into two, and the original ID is shared.

Why it fails: MongoDB does not have a native 'split' mechanism for documents. Every document must have a unique _id. If you need to break up data, you must implement the application logic to move data to a separate collection or a different document structure; the database will not do this for you.