Refer to the Exhibit Practice Questions

Display an error message to the user and stop.

Why it fails: Giving up immediately provides a poor user experience. Since the error is explicitly labeled as transient, it is intended to be retried. By simply stopping, the application fails to handle standard distributed system behavior, which degrades reliability and forces users to manually trigger the operation again.

Retry the individual failed operation only.

Why it fails: In a transaction, you cannot retry a single operation. You must re-run the entire transaction logic from the start to ensure data atomicity and consistency. Retrying just one operation inside a multi-document transaction is not a supported pattern and would likely lead to incomplete or invalid data state.

Ignore the error and continue with the next request.

Why it fails: Ignoring errors in a transaction is catastrophic, as it leads to partial data updates or corrupted application state. If an operation fails, the entire transaction block must be handled, and proceeding without ensuring the previous transaction finished correctly will result in unpredictable data integrity issues across the cluster.

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.

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.

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.

The '_id' field is invalid.

Why it fails: The '_id' field shown is a valid ObjectId, which is the standard primary key in MongoDB. It conforms to the required 12-byte format, so the insertion would not fail due to this field. The issue lies elsewhere in the document structure, specifically with the reserved character usage in field names.

The field 'metadata' is a reserved keyword.

Why it fails: The term 'metadata' is not a reserved keyword in MongoDB. Users are free to use this term for field names in their documents. The failure of the document is strictly related to the use of reserved characters in the nested field, not due to the choice of the parent key name.

The value 'null' is not allowed for the 'last_login' field.

Why it fails: MongoDB fully supports the null data type. Storing a null value is perfectly acceptable and common for fields that have no value or are not yet set. The failure is not caused by the data type, but rather by the illegal naming convention used for the parent object's key.

The Linking Pattern.

Why it fails: The linking pattern involves storing an ID in one collection that refers to a document in another. The exhibit shows the actual order data embedded within the user document, not just a reference ID. Therefore, this is not a linking pattern, as no separate order collection exists here.

The Polymorphic Pattern.

Why it fails: Polymorphic patterns are used when documents in a collection have different structures. Here, the 'orders' array contains consistent sub-document objects. There is no evidence of varying schemas or polymorphic types, so this pattern does not apply to the provided JSON structure which is clearly consistent and deeply nested.

The Computed Pattern.

Why it fails: The computed pattern involves storing calculated values within a document to improve read performance. While the total field is a value, it is a property of the order, not a computed summary of multiple different operations or metrics. The exhibit shows a simple relationship, not a complex computed schema.

It forces all documents to follow a strict schema.

Why it fails: Dynamic mapping actually removes the requirement for a strict schema, as the indexer infers types and indexes all fields automatically. This approach is the opposite of a strict schema approach, where you would explicitly define field types and exclusions for better control over the search index structure.

It prevents the creation of any custom field mappings.

Why it fails: Dynamic mapping acts as a fallback or base configuration. You can still define specific field mappings alongside a dynamic configuration. The dynamic setting simply ensures that fields not explicitly defined in the index definition are still indexed by the system using an inferred data type.

It disables the indexing of nested object fields.

Why it fails: Dynamic mapping includes nested object fields by default. It traverses the document structure, including embedded objects and arrays, and indexes them accordingly. If you wanted to exclude specific fields or handle nested structures differently, you would need to use static or custom mapping definitions instead.

Terminate the application immediately and alert the database administrator.

Why it fails: Terminating the application is excessive for a transient error. These errors are meant to be handled gracefully by the application code. A well-designed MongoDB client implementation should expect these errors and retry the transaction block, which allows the operation to proceed without manual intervention or service downtime.

Retry the specific failed write operation only, outside of the transaction.

Why it fails: Retrying a write outside the transaction violates the atomicity of the operation. If a transaction fails, the entire unit of work must be retried as a whole to ensure data integrity. Partial retries would leave the database in an inconsistent state, defeating the purpose of using multi-document transactions.

Hard-code a try-catch block to skip the transaction and log the error.

Why it fails: Skipping the transaction entirely means the data update is lost, which is unacceptable for business-critical operations. The goal of transaction management is to ensure success or total rollback, not to ignore failed updates. Failing to retry will result in data inconsistencies that can lead to significant application bugs.

They are excluded from the results.

Why it fails: MongoDB does not silently drop documents during a $group stage. If the grouping field is missing, the engine assigns them to a group identified by 'null'. This ensures data integrity and prevents the accidental loss of records that simply lack specific field values in their current schema structure.

The aggregation throws an error.

Why it fails: The aggregation engine does not require fields to be present in every document. It gracefully handles missing fields by substituting them with a null value for the purpose of the group identification. Consequently, the query runs successfully without error, aggregating the incomplete documents into a null group.

They are grouped individually as unique documents.

Why it fails: Grouping logic aggregates documents based on the equality of the _id expression. Because all missing fields evaluate to null, they are considered equal in the context of the grouping operation. Therefore, they are merged into a single bucket rather than being treated as separate individual entries.

It removes the 'details' field entirely from the resulting documents.

Why it fails: $unwind does not remove fields; rather, it expands them. It takes the array stored in the 'details' field and creates a new, separate document for every single element found inside that array, effectively flattening the structure so each record contains a single item instead of an array.

It merges all elements of the 'details' array into a single string.

Why it fails: $unwind does not perform string concatenation or merging of array elements. Its sole purpose is the deconstruction of arrays into multiple separate document instances. Attempting to use it for data conversion or formatting would result in unexpected structural changes rather than the desired string output.

It sorts the 'details' array in ascending order.

Why it fails: $unwind does not perform any sorting operations on the array elements. To sort an array, you would need to use a separate $sort stage or utilize the $sortArray operator within a $project stage before reaching the $unwind stage to ensure the output documents follow a specific order.

The Subset pattern.

Why it fails: The Subset pattern involves keeping only a small amount of data in the main document to ensure it stays small. While the exhibit is small, the presence of a calculated total suggests a focus on performance optimization for reads rather than just keeping document size under control.

The Polymorphic pattern.

Why it fails: The Polymorphic pattern is used when documents in a collection have similar but not identical structures. The exhibit shows a standard order document; there is no evidence of different document types being handled within the same collection or a need to support flexible schemas in the way described.

The Schema Versioning pattern.

Why it fails: The Schema Versioning pattern involves adding a version field to documents to manage updates to the schema over time. The exhibit lacks a version field and does not show any signs of a migration strategy, focusing instead on a specific field calculation, which is not the purpose of versioning.

The index will be used to quickly find all documents where 'type' is 'book'.

Why it fails: The index was created on the entire 'metadata' object, not its constituent parts. MongoDB treats the whole subdocument as a single opaque value in this index. Therefore, a query targeting a specific nested field like 'metadata.type' cannot traverse this index and will instead result in a collection scan.

The index will be used, but performance will be slower than a dot-notation index.

Why it fails: There is no partial use of a whole-document index for sub-field queries. The query engine cannot partially match the internal contents of the indexed BSON blob. It either matches the entire object exactly (including all fields in the correct order) or it doesn't use the index at all for that filter.

The index build will fail because metadata is a nested document.

Why it fails: Indexing a nested document is a perfectly valid operation in MongoDB. It is often used when applications need to perform exact matches on entire objects. However, it is a common mistake to assume this index also covers the individual fields within that object, which is not how the storage engine functions.

The $project stage is too slow.

Why it fails: $project is generally efficient, but the issue here is the sequence, not the stage itself. Performing projections on the full collection before filtering is inherently wasteful because you are transforming data that you will ultimately discard in the subsequent $match stage, leading to unnecessary CPU usage.

The _id: 0 syntax is invalid.

Why it fails: The syntax _id: 0 is perfectly valid in a $project stage to exclude the _id field from the result set. It is a standard practice when you only want to retrieve specific user data without including the auto-generated ObjectID, so this is not a cause for suboptimal performance.

$match cannot follow $project.

Why it fails: The aggregation pipeline allows any stage to follow any other stage as long as the output of the previous stage satisfies the input requirements of the next. You can absolutely put $match after $project, but doing so is inefficient for performance reasons, not because it is syntactically disallowed.

$group

Why it fails: The $group stage is used for aggregating data to compute sums, averages, or other metrics across a collection of documents. It does not possess the capability to deconstruct arrays into individual documents, as its primary purpose is to collapse multiple documents into a single aggregate result per group key.

$project

Why it fails: While $project can reshape documents, it cannot multiply the number of documents in a pipeline based on array content. It is meant for field inclusion, exclusion, or computed transformation, but it remains a one-to-one mapping operation and cannot perform the expansion required to isolate individual array elements.

$match

Why it fails: The $match stage is a filtering operator used to pass only those documents that meet specified conditions. It has no functionality related to document expansion or array deconstruction; it strictly reduces the document stream rather than modifying the internal structure of the documents that successfully pass through the filter.

The Bucket pattern.

Why it fails: The Bucket pattern involves grouping data into documents based on specific criteria like time or count to manage document size. The exhibit shows a key-value structure within an array, which does not represent a grouping of time-series data or a collection of logs, but rather individual entity attributes.

The Extended Reference pattern.

Why it fails: The Extended Reference pattern involves embedding commonly used fields from a referenced document to avoid joins. The exhibit shows internal attributes of a single entity, not external references to another document. There is no field here that acts as a link to another collection's data for performance optimization.

The Computed pattern.

Why it fails: The Computed pattern involves storing the results of calculations within the document to avoid repeating the math during read operations. The exhibit shows raw data attributes, not pre-calculated results or aggregates. Storing pre-computed values is a specific strategy meant to optimize read-heavy workloads, which is not shown here.