Philosophy and Features practice questions

Documents must have an identical set of fields within a collection.

Why it fails: MongoDB supports schema flexibility, meaning documents within the same collection can have different structures. Requiring identical fields would mimic a rigid relational table, which limits the ability to store polymorphic data and hinders the developer's ability to evolve the application schema over time as requirements change.

All documents are limited to a maximum size of 64MB.

Why it fails: MongoDB enforces a strict 16MB limit on the size of a single BSON document. This constraint ensures that the database maintains performance and prevents operations from consuming excessive memory. A 64MB limit is incorrect and does not align with the standard documented constraints of the database engine.

Joins are impossible to perform in MongoDB queries.

Why it fails: While the primary goal of the document model is to avoid joins through embedding, MongoDB supports the $lookup operator within the aggregation framework. This allows for left outer joins between collections when data relationships require normalization, providing flexibility for specific querying requirements that cannot be met by embedding.

The Aggregation Framework.

Why it fails: The Aggregation Framework is for data processing and pipeline transformations. It operates at the query layer and does not control the underlying storage engine's memory cache or eviction policies. Cache management is handled entirely by the storage engine to ensure the overall stability of the database process.

The Replica Set election protocol.

Why it fails: Replica set protocols manage node state and failover. They are concerned with high availability and consensus across the cluster. They do not interact with the memory allocation or page cache eviction policies of the local storage engine, which are local hardware and resource management concerns for the node.

The Sharding balancer.

Why it fails: The sharding balancer is responsible for moving chunks of data between shards to ensure even distribution. While it impacts network and disk I/O, it does not directly manage the memory cache of the storage engine. Cache management is localized to the WiredTiger engine instance running on each server.

Primary nodes automatically rebalance data without user intervention.

Why it fails: Data rebalancing is managed by the balancer process, which runs on the primary mongos or config server. While the balancer automates chunk movement, it is a background system task, not a direct function of the primary node in a replica set which handles data consistency.

Horizontal scaling is achieved by adding more CPUs to a single node.

Why it fails: Adding CPU or RAM to a single machine is vertical scaling. MongoDB is built for horizontal scaling, where performance is increased by adding more nodes to the cluster. Vertical scaling has physical limits, whereas horizontal scaling allows for theoretically infinite growth across distributed commodity hardware.

Applications must perform manual routing to locate specific shards.

Why it fails: The mongos query router handles all shard location logic. Applications connect to the mongos instance as if it were a single server, and the router transparently directs queries to the appropriate shard, shielding the application from the complexities of the underlying sharded cluster architecture.

Master-slave setups are not supported by the protocol.

Why it fails: Master-slave replication was the original method in very early versions of MongoDB. It is now deprecated in favor of replica sets because it lacks the automated failover and robustness required for high-availability production environments, not because the protocol doesn't support the configuration.

Master-slave limits the number of nodes in a set.

Why it fails: While master-slave configurations have different limitations than replica sets, the primary driver for switching to replica sets is the automation of the election process, not a specific restriction on the number of nodes. Scalability is handled by sharding, regardless of the replication method.

Write concern w:1 and read concern local

Why it fails: Write concern w:1 only acknowledges the write on the primary, so a primary step-down immediately after acknowledgment could roll back the write before it replicates. Read concern local returns data that may not have been replicated to a majority and can be rolled back. Neither setting provides the durability and consistency guarantees required by the compliance team for trade records.

Write concern w:majority and read concern local

Why it fails: While w:majority ensures the write is durable across a majority of nodes, read concern local does not guarantee that reads see only majority-committed data. A read with local could return data that later rolls back if the primary fails before replication completes. The compliance team requires both durable writes and consistent reads, so this pairing is insufficient.

Write concern w:0 and read concern majority

Why it fails: Write concern w:0 is fire-and-forget with no acknowledgment, so the client has no confirmation that the write reached even the primary. This directly violates the requirement for majority acknowledgment. Read concern majority may return consistent data, but the lack of write durability makes this combination unsuitable for regulated trade records that must survive primary failures.

w:2

Why it fails: Write concern w:2 requires acknowledgment from the primary and one secondary, totaling two members. This falls short of the required three members. Although w:2 is more durable than w:1, it still does not satisfy the explicit requirement that at least three members acknowledge the write before the client receives confirmation.

w:majority

Why it fails: Write concern w:majority requires acknowledgment from a majority of voting members. In a five-member replica set, a majority is three members. While this also results in three acknowledgments, it is defined as majority, not a fixed count of three. The application specifically requires at least three members, and w:majority would also satisfy that, but it is not the explicit numeric setting requested. However, w:3 is more precise for the stated requirement. The distinction is that w:majority adapts to membership changes, while w:3 is fixed.

w:1

Why it fails: Write concern w:1 only requires acknowledgment from the primary, not three members. This does not meet the application's requirement for acknowledgment from at least three members. While w:1 offers the lowest latency, it provides the weakest durability guarantee and would not protect against the loss of the primary before replication to other members.

Index intersection

Why it fails: Index intersection allows MongoDB to use multiple indexes to fulfill a query, but it does not automatically create indexes based on workload patterns. It requires existing indexes and may not be as efficient as a single compound index. The team needs automatic index creation, which index intersection does not provide. It is a query execution strategy, not an optimization advisor.

Automatic index creation

Why it fails: MongoDB does not have a feature called automatic index creation that analyzes workloads and creates indexes without human intervention. Indexes must be created explicitly by a database administrator or through a tool. This option is a distractor because it sounds plausible but is not a built-in MongoDB feature. The team would need to use a third-party tool or manual analysis.

The Query Optimizer

Why it fails: The query optimizer evaluates candidate plans and selects the most efficient one for a given query shape, but it does not create new indexes automatically. It can only choose from existing indexes. If no suitable index exists, the optimizer will still choose a collection scan. Therefore, it cannot automatically optimize performance based on workload patterns without manual index creation.

Replica sets use a shared-nothing architecture where each member stores a different subset of the data.

Why it fails: In a replica set, each member stores a complete copy of the data set, not a subset. This is different from a sharded cluster, where data is partitioned across shards. Replica sets provide redundancy and high availability through full data replication, not through data partitioning. The shared-nothing architecture with data subsets applies to sharding, not replica sets.

Replica sets can have members in different data centers for disaster recovery.

Why it fails: While replica sets can have members in different data centers, this is not a characteristic inherent to all replica sets. It is a deployment choice for disaster recovery and can introduce latency. The question asks for characteristics of replica sets, and this is an optional configuration, not a defining feature. Therefore, it is not one of the two correct choices.

Replica sets require a minimum of three members to function.

Why it fails: A replica set can function with as few as two members, though a three-member set is recommended for redundancy and automatic failover. With only two members, if one fails, the remaining member cannot elect itself as primary because it lacks a majority. Therefore, a minimum of three members is not strictly required to function, but it is required for automatic failover in most cases. This statement is not a characteristic of all replica sets.

Normalize all data into separate collections to eliminate redundancy.

Why it fails: Normalizing data leads to frequent application-level joins or multi-document transactions to retrieve a complete entity view. While this reduces data duplication, it significantly increases the latency for read operations and complicates write logic, which contradicts the goal of maximizing throughput in a high-traffic environment.

Implement a strict relational schema to enforce referential integrity.

Why it fails: Strict relational schemas require joins across tables to assemble objects. In MongoDB, enforcing referential integrity at the database level often results in cross-collection dependencies. This forces the application to use multi-document transactions to maintain consistency, which decreases throughput and negates the performance benefits of the document model.

Use the GridFS specification for all user-generated content.

Why it fails: GridFS is specifically designed for storing large files that exceed the 16MB BSON document limit. It is not an appropriate strategy for general application data modeling. Using GridFS for standard transactional data would introduce unnecessary complexity and performance degradation without providing any benefit for atomicity or throughput.

It forces data normalization for better storage efficiency.

Why it fails: This approach is the opposite of normalization. By embedding the array directly, the data is denormalized. While this can increase storage usage slightly, it significantly improves read performance by avoiding joins, which is a deliberate trade-off in MongoDB to favor application performance and data locality.

It enforces referential integrity between products and tags.

Why it fails: Referential integrity is not enforced for embedded data structures. MongoDB does not automatically validate the existence of tags or maintain links between collections. This responsibility is delegated to the application layer, which is a common trade-off for the performance gains achieved by avoiding cross-collection relational constraints.

It requires a multi-document transaction to update the tags.

Why it fails: Updating an array within a single document is an atomic operation performed on that document. No multi-document transaction is required. Because the update is scoped to one document, it is highly efficient and avoids the performance penalties associated with distributed transaction coordination across multiple collections or nodes.

BSON is human-readable and easier to debug than JSON.

Why it fails: BSON is a binary format and is not intended to be human-readable. While JSON is text-based and easy for humans to read, BSON is optimized for machine traversal and storage efficiency. Debugging BSON typically requires tools that translate the binary data into a readable format like JSON.

BSON supports fewer data types than standard JSON.

Why it fails: BSON is designed to support more data types than JSON. While JSON only supports basic types like strings, numbers, and booleans, BSON includes native support for Date, BinData, ObjectId, and Timestamp, which are essential for database operations and ensuring data integrity across distributed systems.

BSON is mandatory for communication with the shell only.

Why it fails: BSON is the primary storage and wire protocol format for MongoDB. It is used for disk storage, intra-node replication, and network communication between the driver and the server. It is not limited to the shell, as it is foundational to the entire operation of the MongoDB database engine.

Horizontal sharding of the data.

Why it fails: Sharding is used for horizontal scalability by distributing data across multiple machines. While it helps with large datasets and throughput, it does not inherently provide high availability. A sharded cluster still relies on replica sets for each shard to ensure that data remains available if a node fails.

The use of the Aggregation Framework.

Why it fails: The Aggregation Framework is a powerful tool for data processing and analysis within MongoDB. While it is essential for complex queries and data transformation, it has no impact on high availability or system redundancy. It is an application-side feature rather than an infrastructure or architectural resilience feature.

Strict enforcement of ACID transactions.

Why it fails: While MongoDB supports multi-document ACID transactions, this feature ensures data integrity and consistency, not service availability. Availability is a function of the deployment topology and automated recovery mechanisms, whereas transactions are a feature of the database's consistency model, which operate independently of the node's uptime.

Strict, static schema enforcement at the storage layer.

Why it fails: MongoDB is intentionally designed to be schema-flexible, not schema-strict. Storing data without a fixed schema is a foundational design choice that allows for rapid iteration and agility. Enforcing strict static schemas at the storage layer would contradict the core philosophy of the document model and limit developer speed.

Global dependency on a single centralized primary node.

Why it fails: MongoDB is a distributed system designed for resilience. While replica sets have a primary node, the system is not dependent on a single global primary. It supports distributed deployments and geographic distribution to ensure that the system remains operational even in the face of widespread regional failures.

It forces the use of fixed-width records for performance.

Why it fails: MongoDB documents are not fixed-width. They are variable-length BSON structures that can grow or shrink as data is added or removed. The flexibility of variable-length documents is a key feature that allows for polymorphic data, and forcing fixed-width records would negate this primary architectural advantage.

It ensures that no data can ever be duplicated.

Why it fails: The document model encourages some level of data denormalization to improve read performance. Duplication is often an intentional design decision in document databases to increase speed. The goal is not to eliminate all redundancy, but to optimize the data access pattern for the application's specific needs.

It prevents the database from using indexes on fields.

Why it fails: MongoDB supports extensive indexing of document fields, including nested fields and arrays. The document model does not limit indexing capabilities; rather, it provides powerful features like compound indexes and multi-key indexes that allow developers to query deeply nested data with high efficiency, far beyond simple flat-table indexing.

It guarantees that all reads are always from the primary.

Why it fails: Write concern relates to the persistence of write operations, not the source of read operations. Read preference settings determine which nodes can serve read requests. You can read from secondaries even if write concern is set to acknowledge only the primary, provided the application handles eventual consistency.

It automatically enables sharding across regions.

Why it fails: Write concern is a configuration setting for individual operations or the cluster, not an infrastructure provisioning feature. It does not control data distribution or sharding. Sharding is a separate architectural deployment pattern that must be configured through cluster management, independently of the write acknowledgment settings used for data durability.

It forces every node to process every write request.

Why it fails: Write concern only specifies how many nodes must acknowledge a write for the client to receive a success message. It does not require every node in a cluster to process the write. The replication process happens asynchronously or synchronously based on the configuration, but it is not a blocking broadcast.

The database cannot store data if it doesn't have a template.

Why it fails: This describes a schema-enforced system. MongoDB's schema-less nature is the exact opposite: it allows for the insertion of data without pre-defining a template. Any valid BSON document can be inserted, providing the developer with maximum flexibility to store varying types of data in a single collection.

The database does not support data types for fields.

Why it fails: MongoDB is definitely typed. Each field within a BSON document has a specific type (e.g., String, Int, Date). Schema-less refers to the structure of the collection (the document schema), not the absence of data typing. MongoDB is robust and enforces data types during query and write operations.

Indexes can only be created on fields that exist in all documents.

Why it fails: MongoDB supports sparse indexes, which only include entries for documents that actually contain the indexed field. This is a common pattern for schema-less data, allowing you to index optional fields without requiring them to be present in every document across the entire collection, maintaining high query performance.

Requirement for strict normalization of all data.

Why it fails: Normalization is the hallmark of relational databases. In MongoDB, denormalization is often encouraged to optimize for performance. Requiring normalization would force developers to use multiple joins, which undermines the primary performance and simplicity benefits of the document model's design philosophy for high-concurrency, web-scale applications.

Guaranteed consistency through mandatory schema migrations.

Why it fails: Schema migrations are a significant pain point in relational databases. MongoDB's schema-less model eliminates the need for these migrations, which is a major benefit for developer productivity. Suggesting that mandatory migrations are a benefit is factually incorrect as they represent administrative overhead and potential downtime.

Automatic translation of SQL queries to BSON.

Why it fails: MongoDB does not automatically translate SQL to BSON. While some middleware tools exist, the database natively uses the MongoDB Query Language (MQL). This is not a benefit of the model itself; rather, it represents a fundamental difference in the query interfaces between the two database types.

Applications must manually hardcode all secondary IP addresses.

Why it fails: Modern MongoDB drivers use a 'seed list' approach. You provide a list of one or more hostnames, and the driver automatically discovers the entire replica set topology. Manually hardcoding IP addresses is an obsolete practice that leads to fragile applications that fail if nodes in the cluster change.

It mandates that all reads must be 'strong' consistency.

Why it fails: MongoDB offers configurable read and write concerns. While 'majority' consistency provides strong guarantees, applications can choose different consistency levels to optimize for performance. It is not mandatory to use strong consistency if the application use case can benefit from lower latency through lower consistency levels.

It forces the application to implement custom failover logic.

Why it fails: One of the key benefits of MongoDB replica sets is that the failover logic is handled automatically by the server-side consensus protocol (Raft). The driver handles the reconnection and re-discovery, meaning the application developer does not need to write custom code to handle node failover events.

Always embed to prevent any possibility of data duplication.

Why it fails: Embedding often results in some data duplication. This is a common and acceptable trade-off in MongoDB. The goal is to optimize for the access pattern, not to strictly avoid duplication. If you strictly avoid duplication, you would be forced into a relational design, which causes performance issues.

Always reference to keep the database size as small as possible.

Why it fails: While referencing keeps document size smaller, it frequently results in multiple queries to assemble a single object. This significantly increases latency and puts unnecessary strain on the database engine. Performance, not disk space, is usually the more important metric for modern high-performance application requirements.

Use embedding for all data to ensure ACID compliance.

Why it fails: ACID compliance is a feature of the MongoDB storage engine and can be achieved with both embedded and referenced data models. Embedding does not inherently provide better ACID compliance; it only provides atomic updates to the document, which is just one aspect of overall transactional data integrity.

It stores user credentials for database authentication.

Why it fails: User credentials are stored in the 'admin' database within specific collections for security and access control. The OpLog is strictly for data modification operations and has nothing to do with authentication or authorization. Storing credentials in the OpLog would be a major security risk.

It is used for storing index definitions and metadata.

Why it fails: Indexes and metadata are managed by the storage engine in specialized internal collections. The OpLog records changes to data, not the structural definitions of the collections or indexes themselves. It tracks 'what happened' to the data, not the configuration of the database schema or index structure.

It acts as a permanent, immutable backup of all data.

Why it fails: The OpLog is a capped collection, meaning it has a fixed size and is circular; it overwrites the oldest entries as new operations arrive. It is not a permanent backup solution. For long-term backups, one must use tools like mongodump or snapshot-based backup strategies, not the OpLog.