MongoDB Skills Assessment

MongoDB's embedding strategy is correct when data is always read together, the relationship is one-to-few (bounded array size), and write patterns operate on the parent document. Embedding comments inside the article document means a single find() retrieves everything needed with no joins. The bounded size (up to 50 comments) prevents the document from approaching MongoDB's 16MB document size limit. A separate collection with $lookup (option C) is appropriate when comments need to be queried independently or when the array could grow unboundedly, creating unbounded document growth risk.

A compound index on {customer_id: 1, order_date: -1} directly serves this query: MongoDB uses the customer_id portion to narrow the result set to one customer's orders, then uses the order_date portion to return results in sorted order without an in-memory sort step. Without this index, MongoDB performs a full collection scan of 50 million documents. A single index on order_date (option D) would not help filter by customer_id efficiently. Increasing RAM helps with working set caching but does not eliminate the inefficiency of a collection scan. The index field order must match the query's filter-then-sort pattern.

MongoDB has supported multi-document ACID transactions across replica sets since version 4.0, and across sharded clusters since 4.2. This is the correct tool for operations that must atomically modify multiple documents - if the credit fails, the debit is automatically rolled back. Sequential updates without a transaction (option A) create a window where account A is debited but account B has not yet been credited, corrupting the ledger if a failure occurs mid-operation. Two-phase commit (option D) was a pre-4.0 workaround that is now obsolete. Embedding both accounts in one document (option C) is only feasible if both accounts are owned by the same entity.

In MongoDB aggregation pipelines, the order of stages critically affects performance. A $match stage placed at the very beginning can use an index to filter the document set before expensive operations like $unwind and $group are applied. If only the last 30 days of orders are needed for the report, adding $match: {order_date: {$gte: startDate}} at the start could reduce the working set from 20 million to a few hundred thousand documents before any unwind or grouping occurs. $project at the end reduces output size but does not reduce the work done by upstream stages. allowDiskUse prevents out-of-memory errors but does not speed up the pipeline.

PostgreSQL with JSONB is a mature approach to exactly this tension. Core entities (users, orders, products) get defined columns with constraints and indexes. Rapidly evolving attributes (user preferences, feature flags, metadata) go in a JSONB column that requires no schema migrations. PostgreSQL's ACID guarantees, foreign keys, and JOINs remain available for relational needs. MongoDB's 'schemaless' reputation is somewhat misleading - applications enforce schema in application code, which is harder to audit and refactor than a database-level schema. The 2024 Stack Overflow survey shows PostgreSQL as the most-used database among professional developers for the fourth consecutive year.

False. MongoDB collections are schema-flexible by default: documents in the same collection can have entirely different fields and data types. This is both a feature and a risk. The feature is rapid iteration during development - you can add new fields without migrations. The risk is that without schema validation (using $jsonSchema validators or an ODM like Mongoose), inconsistent documents accumulate and queries become unpredictable. Most production MongoDB applications enforce schema validation either at the database level via collection validators or at the application layer via ODM schemas.

True. The $lookup stage performs a left outer join from the current collection to a foreign collection in the same database, merging matching documents as a new array field. Since MongoDB 3.6, $lookup supports complex join conditions beyond simple equality, including uncorrelated subpipelines. However, $lookup is generally slower than embedding for frequently read data because it requires cross-collection coordination. Overreliance on $lookup often signals a document modeling problem - data that is always read together should usually be embedded. $lookup is most appropriate for large reference data or when the joined data is queried independently.

Indexes should be created to match the actual query patterns. A single-field index on city enables efficient document retrieval for city-based filters, reducing full collection scans. A text index on bio enables MongoDB's full-text search capabilities, including tokenization, stemming, and relevance scoring. Creating an index on every field (option C) is an anti-pattern: each index consumes memory from the working set and imposes write overhead on every insert and update, degrading write performance. MongoDB does not magically handle filtering in memory efficiently (option D) without indexes on collections of meaningful size.

MongoDB embedding vs. referencing decisions follow the rule: embed when data is always read together and bounded in size; reference when data is unbounded, frequently queried independently, or shared across many parent documents. A user's address is bounded (one record) and always read with the user - embed. A user's posts are unbounded (thousands possible) - embedding them would cause documents to grow without limit, approaching the 16MB cap - reference by ID array. When posts are read without author context (such as a feed), storing only a user_id reference avoids over-fetching the full author object unnecessarily.

$match is MongoDB's filter stage in the aggregation pipeline, equivalent to a WHERE clause in SQL. When placed at the beginning of the pipeline, $match can use collection indexes to reduce the number of documents that downstream stages (like $group, $unwind, $lookup) need to process. This is the single most impactful optimization for aggregation pipeline performance. A $match placed after a $group, by contrast, filters on the grouped output and cannot use collection indexes, since the grouped results are computed in memory.

BSON (Binary JSON) is MongoDB's internal document storage format. It extends JSON with additional types (Date, ObjectId, Binary, Decimal128, and more), is traversable efficiently without full deserialization, and supports length-prefixed strings and arrays for faster parsing. BSON is not human-readable like JSON; MongoDB drivers transparently convert between BSON and native language types. Understanding BSON matters for performance: BSON documents have a 16MB size limit, and certain BSON types (like Decimal128 for financial calculations) should be preferred over doubles for precision-sensitive data.

Each pipeline stage transforms the document stream in a specific way. $match filters using query predicates and can leverage indexes when placed first. $group collapses multiple documents into grouped summaries using accumulators like $sum, $avg, $min, $max, and $count. $sort orders the current document stream by one or more fields. $lookup performs a left outer join with another collection, adding matched documents as an array field. These four stages form the core of most analytical aggregation pipelines in MongoDB.

MongoDB schema design is query-driven: the data model must be shaped around how the application will read and write data, not around the entities themselves. Defining query patterns first ensures the schema embeds or references data in the access pattern that the application requires. Index design follows schema design because indexes must match the query patterns and field structure. Schema validation rules enforce data quality. The application is built on top of the validated schema. Load testing reveals real-world performance characteristics, and post-load-test index tuning addresses any remaining slow queries.

MongoDB replica set election is automatic and uses a RAFT-based consensus protocol. When the primary fails, the remaining secondary nodes detect the failure (via heartbeat timeout), and an election begins. The secondary with the most up-to-date oplog and eligible configuration wins the election and becomes the new primary. With 3 nodes, a majority (2) is still available, satisfying the quorum requirement for an election. The process typically completes in 10-30 seconds. This automatic failover is why replica sets are the minimum recommended configuration for any production MongoDB deployment.

explain() is MongoDB's query execution plan analyzer. When appended to a find(), aggregate(), or update() call, it returns a document describing how MongoDB will (or did) execute the operation. Key fields to examine include winningPlan (which index, if any, was used), COLLSCAN vs. IXSCAN (collection scan vs. index scan), nReturned vs. totalDocsExamined (ratio should be close to 1:1 for an efficient query), and executionTimeMillis. Running explain('executionStats') provides actual execution metrics rather than just the plan. It is the essential first step in diagnosing slow queries.