Q: What is the _id field, and what is inside an ObjectId?

Every document in a standard collection needs an _id that acts as its primary key. It must be unique within the collection, it's immutable once set, and it can be any BSON type except an array, a regex or undefined. MongoDB automatically creates a unique index on _id for every collection. If you insert a document without one, the driver generates an ObjectId. An ObjectId is 12 bytes: - a 4-byte timestamp: seconds since the Unix epoch - a 5-byte random value generated once per client process - a 3-byte incrementing counter, initialized to a random value So IDs are generated client-side with no coordination, and getTimestamp() recovers the creation time. Because they roughly increase over time, sorting by _id approximates insertion order, but it isn't strictly monotonic across different clients. That same "always increasing" property makes a plain ranged ObjectId a poor shard key.

Q: Why do we need indexes in MongoDB, and which index types does it support?

Without a suitable index a query has to do a collection scan (COLLSCAN), reading every document. An index is an ordered B-tree of field values pointing to documents, so the server can jump to matching entries and even return results in index order without sorting. Index types: - Single field and compound (several fields, order matters) - Multikey: created automatically when an indexed field holds an array - Text: keyword search with stemming; one per collection - Geospatial: 2dsphere and 2d - Hashed: used mainly for hashed sharding - Wildcard: { "$": 1 } for unpredictable field names Index properties** include unique, partialFilterExpression, sparse, TTL (expireAfterSeconds), hidden and a collation for case-insensitive matching. Every collection gets a unique _id index. The trade-off: each index costs RAM and disk, and slows every insert, update and delete that touches its fields.

Question 1

What is MongoDB, and when would you choose it over a relational database?

Accepted Answer

MongoDB is a document database. It stores records as BSON documents (JSON-like, with nested objects and arrays) grouped into collections, with a flexible schema, a rich query language, secondary indexes, an aggregation framework, built-in replication through replica sets and horizontal scaling through sharding. I'd pick it when: - The data is naturally hierarchical or varies per record: product catalogs, user profiles, content, events, IoT readings - The app mostly reads and writes whole aggregates, so one document can hold what would be several joined tables - The schema evolves quickly, or the dataset will outgrow one server I'd lean relational when the domain is dominated by many-to-many relationships and ad hoc joins, or when most operations touch many entities transactionally. MongoDB does have ACID multi-document transactions and schema validation, so the real decision is about data shape and access patterns, not "no transactions".

Question 2

How does MongoDB compare with a SQL database? Map the main concepts and explain the key differences.

Accepted Answer

The terminology maps fairly directly: - table → collection, row → document, column → field - primary key → the _id field - join → embedding related data, or $lookup in an aggregation - GROUP BY → the $group stage The bigger differences are in philosophy. SQL databases enforce a fixed schema and normalize data by entity, then join at query time. MongoDB lets documents in a collection differ (you can add $jsonSchema validation when you want rules), and you model around access patterns, storing data that's read together in one document. MongoDB doesn't enforce foreign keys, so referential integrity is the application's job. On scaling, MongoDB has sharding built in, whereas many relational setups scale up first. Both offer ACID transactions; in MongoDB a single-document write is always atomic, and multi-document transactions exist but cost more.

Question 3

What is BSON, and why does MongoDB store BSON instead of plain JSON?

Accepted Answer

BSON is a binary-encoded serialization of JSON-like documents. MongoDB uses it on disk and on the wire for two reasons. First, richer types. JSON only has strings, numbers, booleans, null, objects and arrays. BSON adds ObjectId, Date, 32- and 64-bit integers, doubles, Decimal128 for exact money values, binary data, regular expressions and more, so a date stays a date and you can range-query and index it correctly. Second, efficient traversal. Elements are type-tagged and length-prefixed, so the server can skip over fields without parsing everything. A document is an ordered set of field/value pairs, up to 16 MiB and 100 levels of nesting. Documents live in collections, which live in databases. Both are created implicitly on first insert. When mongosh prints BSON it uses helpers like ObjectId(...) and ISODate(...); drivers exchange it as Extended JSON when text is needed.

Question 4

What is the _id field, and what is inside an ObjectId?

Accepted Answer

Every document in a standard collection needs an _id that acts as its primary key. It must be unique within the collection, it's immutable once set, and it can be any BSON type except an array, a regex or undefined. MongoDB automatically creates a unique index on _id for every collection. If you insert a document without one, the driver generates an ObjectId.

An ObjectId is 12 bytes:

a 4-byte timestamp: seconds since the Unix epoch
a 5-byte random value generated once per client process
a 3-byte incrementing counter, initialized to a random value

So IDs are generated client-side with no coordination, and getTimestamp() recovers the creation time. Because they roughly increase over time, sorting by _id approximates insertion order, but it isn't strictly monotonic across different clients. That same "always increasing" property makes a plain ranged ObjectId a poor shard key.

Question 5

How do you decide whether to embed related data in a document or reference it from another collection?

Accepted Answer

The guiding principle is data that's accessed together should be stored together, and I start from embedding unless there's a reason not to. Embed when: - The child is owned by the parent and read with it, like an order's line items or a user's addresses - The relationship is one-to-few and the array is bounded - You want the parent and children updated atomically in a single-document write Reference when: - The "many" side is large or grows without limit, so the document would bloat toward the 16 MiB cap - The child needs to be queried or updated on its own - The data is shared by many parents and changes often, so duplicating it would be expensive to keep in sync - It's many-to-many Often the answer is a hybrid: reference the full record but embed a few frequently read fields (the extended reference pattern). Always design from the queries the application actually runs.

Question 6

Why do we need indexes in MongoDB, and which index types does it support?

Accepted Answer

Without a suitable index a query has to do a collection scan (COLLSCAN), reading every document. An index is an ordered B-tree of field values pointing to documents, so the server can jump to matching entries and even return results in index order without sorting.

Index types:

Single field and compound (several fields, order matters)
Multikey: created automatically when an indexed field holds an array
Text: keyword search with stemming; one per collection
Geospatial: 2dsphere and 2d
Hashed: used mainly for hashed sharding
Wildcard: { "$**": 1 } for unpredictable field names

Index properties include unique, partialFilterExpression, sparse, TTL (expireAfterSeconds), hidden and a collation for case-insensitive matching. Every collection gets a unique _id index.

The trade-off: each index costs RAM and disk, and slows every insert, update and delete that touches its fields.

Question 7

What is the aggregation pipeline? Walk me through what this query does.

Accepted Answer

The aggregation pipeline is MongoDB's framework for transforming and analyzing data on the server. Documents flow through an ordered list of stages, and each stage's output is the next stage's input, much like a Unix pipe.

This one returns the top five customers by paid revenue this year:

$match filters to paid orders since January. Placed first, it can use an index on status and placedAt
$group makes one document per customerId, summing amount and counting orders with $sum: 1
$sort and $limit keep the five biggest totals; the optimizer merges them into a top-k sort
$project reshapes the output, renaming _id to customerId

Other common stages are $lookup for joins, $unwind to flatten arrays, $addFields/$set, $facet, $count, and $out or $merge to write results to a collection.

Question 8

What is a replica set, and what happens when the primary goes down?

Accepted Answer

A replica set is a group of mongod processes holding the same data. One member is the primary and accepts all writes; it records them in its oplog, a capped collection that secondaries copy and replay asynchronously. Members exchange heartbeats every two seconds. If secondaries can't reach the primary for longer than electionTimeoutMillis (10 seconds by default), an eligible secondary calls an election, and the candidate that wins votes from a majority of voting members becomes primary. The manual says a new primary is typically elected in about 12 seconds or less with default settings. During the election no writes are accepted, but secondaries can keep serving reads if your read preference allows it. Drivers enable retryable writes by default, so many writes are retried once automatically. When the old primary comes back it rejoins as a secondary. Any of its writes that never reached a majority are rolled back, which is why w: "majority" matters. A set can have up to 50 members, but at most 7 voting ones; use an odd number of voters.

Question 9

What is sharding in MongoDB, and what are the components of a sharded cluster?

Accepted Answer

Sharding is horizontal partitioning: a collection's documents are spread across several shards so data size and write throughput can exceed what one server handles. A sharded cluster has three parts: - Shards: each is a replica set holding a subset of the data - mongos routers: the app connects to these; they look up metadata and route each operation to the right shards - Config servers: a replica set storing cluster metadata, such as which ranges live where The shard key, one or more fields chosen per collection, decides where each document goes. Data is split into chunks (contiguous shard key ranges, 128 MB by default), and the balancer migrates chunks to keep data evenly spread. Queries that include the shard key are targeted to specific shards; queries without it become scatter-gather across all shards. Sharding adds real operational complexity, so I'd first make sure indexes, schema and vertical scaling on a replica set are exhausted.

Question 10

Does MongoDB support ACID transactions? Show how you would transfer money between two accounts.

Accepted Answer

Yes, at two levels. A write to a single document is always atomic, including all its embedded documents and arrays. With good modeling, that covers most use cases. For changes across documents or collections, MongoDB has multi-document ACID transactions: on replica sets since 4.0 and on sharded clusters since 4.2. They don't work on a standalone server. Inside a transaction, reads come from a consistent snapshot (on sharded clusters, ask for read concern "snapshot" to guarantee it across shards), commit is all-or-nothing, and no other client sees the changes until commit. In mongosh, session.withTransaction() runs the callback, commits, and retries the whole transaction or the commit on transient errors. Throwing inside the callback aborts and rolls everything back. That's why the snippet checks modifiedCount: the filter balance: { $gte: 100 } makes the debit conditional, and if it matched nothing we throw instead of committing half a transfer. Transactions cost more than single-document writes, so the manual advises against using them as a substitute for good schema design.

Question 11

How do you order the fields of a compound index? Explain the ESR rule with this query.

Accepted Answer

A compound index is sorted by its first field, then by the second within each value of the first, and so on. Two consequences:

Prefix rule: { a: 1, b: 1, c: 1 } supports queries on a, a + b and a + b + c, but not on b alone
Sort direction: it supports sort({ a: 1, b: 1 }) and the exact reverse, but not a mixed { a: 1, b: -1 }

The ESR guideline says: Equality fields first, then Sort fields, then Range fields. Equality first means everything after it stays in sorted order. Sort next lets MongoDB read keys already in placedAt order and skip an in-memory sort. Range last, because a range on total placed before placedAt would break that ordering.

Watch out: $ne, $nin and $regex count as range operators. And if the range filter is very selective, putting it before the sort field (ERS) can examine fewer keys, so confirm with explain().

Question 12

How do you use explain() to check whether a query is efficient? What is the difference between COLLSCAN and IXSCAN?

Accepted Answer

explain() shows the plan the query optimizer chose. It has three verbosity modes: queryPlanner (the default, plan only), executionStats (runs the winning plan and reports counters) and allPlansExecution (also partial stats for rejected plans). In winningPlan, read the stage tree from the leaf up: - COLLSCAN: a full collection scan, reading every document. Fine for tiny collections, a red flag otherwise - IXSCAN: scanning an index range, usually followed by FETCH to load the documents - A SORT stage means an in-memory sort; if it's absent, the index supplied the order Then compare nReturned, totalKeysExamined and totalDocsExamined in executionStats. The ideal is close to 1:1:1. If you examine 50,000 keys to return 20 documents, the index is weakly selective or its field order is wrong. totalDocsExamined: 0 means a covered query. rejectedPlans shows which other indexes the planner considered.

Question 13

How do you choose a good shard key, and what happens if you pick a bad one?

Accepted Answer

I evaluate candidates on four properties:

High cardinality: each distinct key value can live in only one chunk, so a key like continent caps you at seven chunks, and adding more shards won't help
Low frequency: if a few values dominate, their chunks grow huge, can't be split, and become hot spots or jumbo chunks
Not monotonic: with timestamps or ObjectIds, every insert lands in the chunk with the maxKey upper bound, so one shard takes all the writes
Query isolation: the key should appear in most queries so mongos can target one shard instead of scatter-gather

A compound key often satisfies all four, for example { customerId: 1, orderDate: 1 }: customer gives spread and targeting, date adds cardinality. Hashing a monotonic field fixes write hot spots but makes range queries broadcast.

A bad key used to be permanent. Now you can refine it by adding suffix fields with refineCollectionShardKey, or fully reshard with reshardCollection since 5.0, though that's a heavy operation. From 7.0, analyzeShardKey reports cardinality, frequency and monotonicity before you commit.

Question 14

Are updates to a single document atomic in MongoDB? How do you avoid lost updates under concurrency?

Accepted Answer

Yes. Any write to one document is atomic, even if it changes several fields, embedded documents and arrays at once. Other readers see either the old document or the new one, never half of it. The first pattern is a classic lost update: two clients both read stock: 5, both write 3, and one sale vanishes. The fix is to let the server do the math with update operators like $inc, $set, $push or $min, and to put the precondition in the filter. The second statement only matches if at least two units remain, so checking modifiedCount tells you whether the reservation succeeded. This atomicity is per document. updateMany applies atomically to each matched document but not to the set as a whole; other operations can interleave. If several documents must change together, either model them into one document or use a multi-document transaction.

Question 15

How do you write queries with find()? Explain the common query operators used here.

Accepted Answer

find(filter, projection) returns a cursor over matching documents. Separate conditions in the filter are implicitly ANDed. The main operator groups: - Comparison: $eq, $ne, $gt, $gte, $lt, $lte, $in, $nin - Logical: $and, $or, $nor, $not - Element: $exists checks presence, $type checks the BSON type - Evaluation: $regex, and $expr to use aggregation expressions, such as comparing two fields of the same document - Array: $all (contains every value), $size, $elemMatch So this finds working-age users in India or the US, on the pro plan or with more than 100 credits, not soft-deleted, tagged both beta and mobile, who have spent more than their budget. For performance: equality and ranges use indexes well; $ne, $nin and unanchored regexes are rarely selective; a case-sensitive prefix regex like /^abc/ can use an index range.

Question 16

MongoDB has no JOIN keyword. How do you combine data from two collections?

Accepted Answer

There are three options. First, avoid the join by embedding the data, or by copying a few fields you always need (the extended reference pattern). Second, $lookup in an aggregation, which performs a left outer join. For each input document it finds matches in the from collection and puts them in an array field named by as. An order with no customer gets an empty array. $unwind then turns the one-element array into an embedded object, but it drops documents whose array is empty unless you set preserveNullAndEmptyArrays: true. The pipeline form, with let and pipeline, supports extra conditions and sub-queries on the foreign side. Third, application-level joins: query orders, collect the IDs, then one $in query for customers. That's what Mongoose's populate() does. Whichever you choose, index the foreign field. Without one, each lookup can scan the whole foreign collection. If nearly every read needs a join, that's a sign to revisit the schema.

Question 17

What is write concern? Explain w, j and wtimeout, and what the default is.

Accepted Answer

Write concern is the level of acknowledgment you ask for before a write is reported as successful. It trades latency for durability. - w: 0: fire and forget, no acknowledgment - w: 1: the primary applied it. It can be rolled back if the primary fails before replicating - w: "majority": a majority of data-bearing voting members have it. It survives failover - w: <n> or a custom tag name for specific member counts or data centers - j: true: wait until the write is in the on-disk journal - wtimeout: how long to wait for the concern, in milliseconds Since MongoDB 5.0 the implicit default is w: "majority". The exception: with arbiters, if data-bearing voters don't exceed the voting majority, for example primary-secondary-arbiter, the default is w: 1. Gotcha: a wtimeout error doesn't undo anything. The write may already be applied and may still replicate; you only learn the guarantee wasn't confirmed in time, so the retry logic must be idempotent.

Question 18

What is the difference between read concern and read preference?

Accepted Answer

They answer different questions. Read preference decides which member serves the read: - primary (default), primaryPreferred, secondary, secondaryPreferred, nearest - optionally refined with tag sets (for example, "same region") and maxStalenessSeconds to skip lagging secondaries Read concern decides which version of the data is returned, meaning its consistency and durability: - "local" (default): the member's latest data, which might later roll back - "available": similar, lowest latency, with sharding caveats - "majority": only data acknowledged by a majority, so it won't be rolled back - "linearizable": reflects every majority write completed before the read began - "snapshot": a consistent point-in-time view, used in transactions Replication is asynchronous, so reading from secondaries can return stale data even with "majority". Use secondaries for analytics or geo-local reads that tolerate lag, not for read-your-own-writes. Transactions that read must use primary.

Question 19

What MongoDB schema design patterns do you know, and when would you use each?

Accepted Answer

MongoDB documents a catalog of reusable patterns. The ones I reach for most:

Bucket: group many small items, like sensor readings per device per hour, into one document with an array. Fewer documents and smaller indexes
Subset: keep only the hot part in the main document, such as the 10 latest reviews, and the rest in another collection
Extended reference: copy a few frequently read fields of a referenced document, like a customer's name on each order, to avoid joins
Computed: precompute values such as totals or averages on write instead of on every read
Outlier: design for the typical case and flag the rare huge document, then overflow its extras elsewhere
Attribute: turn many similar fields into an array of key/value pairs so one index covers them
Polymorphic: different shapes in one collection, sharing common fields
Schema versioning: a schemaVersion field lets old and new shapes coexist during a migration

Others include approximation, tree, pre-allocation and document versioning. Each trades some write complexity or duplication for faster reads.

Question 20

How do you model one-to-few, one-to-many and one-to-squillions relationships?

Accepted Answer

The size of the "N" drives the choice, along with whether the children stand alone.

One-to-few: embed the children as an array of subdocuments. A person's handful of addresses lives inside the person document, read and written together
One-to-many, up to a few hundred or thousand: store an array of references in the parent, such as a product holding the ObjectIds of its parts. Children are their own documents, and the same approach gives you many-to-many without a join table
One-to-squillions: put a reference to the parent in each child, like log messages each carrying hostId. An array would grow without bound and hit 16 MiB

The rules of thumb behind this: favor embedding unless there's a compelling reason not to; needing to access a child on its own is such a reason; arrays should not grow without bound; don't be afraid of application-level joins if you index properly; and weigh read-to-write ratio before denormalizing a field. Everything depends on the access patterns.

Question 21

What is the maximum document size in MongoDB, and what do you do if your data needs more?

Accepted Answer

A BSON document can be at most 16 MiB. The limit exists so a single document can't consume an excessive amount of RAM, or bandwidth when it's sent over the network. In practice, a document getting anywhere near that size is a modeling smell, usually an array that keeps growing: comments, events, log lines. Every read and update of that document drags the whole thing through the cache, so performance suffers long before the hard limit. Fixes: - Reference the growing children from their own collection instead of embedding them - Use the bucket pattern to cap items per document - Use the subset or outlier pattern to keep only the hot part inline For genuinely large binary content like videos or PDFs, use GridFS, which splits a file into chunks (255 kB by default) stored in fs.chunks with metadata in fs.files. Many teams instead put files in object storage and keep only the URL and metadata in MongoDB.

Question 22

What is a covered query, and how do you confirm one?

Accepted Answer

A covered query is answered entirely from an index, without reading any documents. That's fast because index keys are small and usually in RAM. For a query to be covered: - every field in the filter is in the same index - every field returned is in that index - no filter field is compared to null The classic trap is _id: it's returned by default, so unless it's part of the index, the projection must say _id: 0, as above. Other limits: a multikey index can't cover a query on its array field, and on a sharded collection the index must contain the shard key for a query through mongos to be covered. To confirm, run explain("executionStats"). A covered plan has no FETCH stage, often shows PROJECTION_COVERED, and reports totalDocsExamined: 0 while totalKeysExamined is greater than zero.

Question 23

What is an upsert? What document does this create when nothing matches, and how do you make it safe under concurrency?

Accepted Answer

An upsert is "update if it exists, insert if it doesn't", enabled with { upsert: true } on updateOne, updateMany, replaceOne or findOneAndUpdate.

If a document matches, it just gets views incremented. If none matches, MongoDB builds a new document from the equality conditions in the filter (page and day), applies the update operators, so views becomes 1, and applies $setOnInsert, which only runs on insert. Range conditions like $gt are not copied into the new document, and an _id is generated if none is given. The result reports upsertedId.

The concurrency trap: two clients can both find no match and both insert, creating duplicates. The fix is a unique index on the filter fields. Then exactly one insert wins. When the filter is equality on exactly the unique index's fields, the server retries the losers as updates; otherwise they get a duplicate key error that the app should retry.

Question 24

Explain $push, $addToSet and $pull. How would you keep an array capped at the 50 newest items?

Accepted Answer

All three change arrays atomically inside one document, without rewriting the array from the app.

$push appends a value, creating the array if the field is missing. Pushing an array appends it as one element; use $each to add several
$addToSet adds a value only if it isn't already present, giving set semantics. For subdocuments, the comparison is on the whole value, including field order
$pull removes every element equal to a value or matching a condition, such as all comments by spammer

$push also takes modifiers that all require $each: $position to insert at an index, $sort to order the array, and $slice to trim it. They run in a fixed order: insert, then sort, then slice. The feed update above keeps only the 50 newest items, a simple way to stop an array from growing without bound. $pop removes just the first or last element.

Question 25

What is a projection in MongoDB, and what rules apply when writing one?

Accepted Answer

A projection is the second argument to find() (or a $project stage) that chooses which fields come back. db.users.find({}, { name: 1, email: 1 }) returns only name, email and _id. The rules: - _id is included by default; add _id: 0 to drop it - You can't mix inclusion (1) and exclusion (0) in one projection, except for _id - Use dot notation for nested fields, like "address.city": 1 - Arrays have projection operators: $slice for the first or last N elements, $elemMatch for the first matching element, and positional $ for the element matched by the filter Projections cut network transfer and client memory, and they're required for covered queries. One nuance: unless the query is covered, the server still loads the full document into its cache. Projection shrinks the response, not the disk read, so it isn't a fix for bloated documents.

Question 26

Why do these two queries return different results for the same document? When do you need $elemMatch?

Accepted Answer

When you query array fields with separate conditions, each condition can be satisfied by a different element. In the first query, the element with product: "xyz" satisfies the first condition and the element with score: 10 satisfies the second, so the document matches, even though no single result is "xyz with a score of at least 8".

$elemMatch requires one element to satisfy all conditions together. The xyz element has a score of 5, so the second query correctly finds nothing.

The same thing happens with scalar arrays: { scores: { $gt: 80, $lt: 85 } } matches [90, 70], because 90 is above 80 and 70 is below 85, while $elemMatch: { $gt: 80, $lt: 85 } needs a value actually between them.

So I use $elemMatch whenever I have two or more conditions on the same array element. For one condition, plain dot notation is enough. There's also a projection $elemMatch that returns only the first matching element.

Question 27

What is a TTL index, and how precise is its expiry?

Accepted Answer

A TTL index is a single-field index with expireAfterSeconds. A background task deletes documents once that many seconds have passed since the date in the indexed field. It's ideal for sessions, tokens, caches and temporary logs.

Two styles: a fixed lifetime (lastSeen plus 30 minutes), or expireAfterSeconds: 0 with a per-document expireAt date, so each document expires at its own time.

Things to know:

It's not precise. The TTL monitor runs every 60 seconds, and under heavy load deletes can lag further, so filter on the date too if stale data mustn't be seen
The field must be a BSON Date or an array of dates; with an array, the earliest date counts. Documents where it's missing or not a date never expire
It must be a single-field index: compound indexes ignore expireAfterSeconds, and _id can't be a TTL index
On a replica set only the primary deletes; the deletes replicate like any other write

Question 28

How do you paginate results in MongoDB? Why is skip() a problem on large collections?

Accepted Answer

The simple approach is skip((page - 1) * size).limit(size). It works for small data, but the server still has to walk past every skipped entry, so page 5,000 costs far more than page 1. Results can also shift or repeat while users page, because inserts and deletes move the offsets. For large or infinite-scroll lists I use range-based (keyset or cursor) pagination. Sort on an indexed key, remember the last item returned, and ask for items after it. Each page is an index seek plus limit, so it costs the same at any depth, and concurrent inserts don't cause duplicates. The sort must be unique to be stable. MongoDB's sort isn't stable for equal keys, so add _id as a tie-breaker, as in the snippet, backed by an index like { status: 1, createdAt: -1, _id: -1 }. The trade-off: you can't jump straight to page 37, which most UIs don't need anyway. The client gets an opaque cursor encoding createdAt and _id.

Question 29

Why does the second insert fail here, and how would a partial index fix it?

Accepted Answer

A unique index stores a null key for documents where the field is missing, and uniqueness applies to that null like any other value. The first user without an email takes the null slot, and the second collides with it. A partial index only indexes documents that match partialFilterExpression. Combined with unique: true, uniqueness is enforced only among documents that have an email, so any number of users can omit it. The filter supports equality, $exists: true, $gt/$lt-style comparisons, $type, $and, $or and $in. Partial indexes also shrink index size, for example indexing only { status: "active" } orders. The catch: the planner uses one only when the query's filter implies the partial filter. A query on email alone may not qualify; include the condition, such as email: { $exists: true }. Sparse indexes do something similar, skipping documents missing the field, but the manual recommends partial indexes because they're more expressive. Note that creating a unique index fails if existing data already has duplicates.

Question 30

How do $unwind and $group work together? Explain this best-sellers report.

Accepted Answer

$unwind deconstructs an array: an order with three items becomes three documents, each holding one item in items. Documents where the array is missing or empty are dropped unless you pass preserveNullAndEmptyArrays: true. $group then collapses documents that share a group key, given as _id. Here each SKU becomes one output document, using accumulators: $sum of quantities, $sum of an expression for revenue, and $avg. Others include $min, $max, $first, $last, $push and $addToSet. Grouping by _id: null aggregates the whole input into one document. Things interviewers look for: - $group output order is not guaranteed, hence the explicit $sort - $group is blocking and each stage is limited to 100 MB of RAM; beyond that it spills to disk when disk use is allowed, which is the default since 6.0, or errors if it isn't - $unwind multiplies document counts, so $match first to shrink the input

Question 31

What is Mongoose, and what are schemas and models?

Accepted Answer

Mongoose is an ODM (object data modeling library) for Node.js that sits on top of the official MongoDB driver. It adds structure to MongoDB's flexible documents from the application side. - A schema declares fields, types, defaults and validators, plus options like timestamps, which adds createdAt and updatedAt - A model is compiled from a schema with mongoose.model(). It's the class you query with (User.find, User.create), and it maps to a collection, by default the lowercased plural of the name, so users - A document is an instance of a model, with change tracking and save() Mongoose casts values (the string "42" becomes a number), validates before saving, and adds middleware, virtuals and populate(). Gotchas: unique: true is not a validator; it only asks Mongoose to build a unique index. Also, update validators don't run on updateOne and similar unless you pass runValidators: true. Schemas are app-side only; other clients can still write anything unless you also add server-side $jsonSchema validation.

Question 32

How does Mongoose populate() work, and how is it different from $lookup? When would you use lean()?

Accepted Answer

You store a reference as { type: Schema.Types.ObjectId, ref: "User" }, then Post.find().populate("author", "name") replaces each author ID with the referenced user document. Under the hood, populate is not a server-side join. Mongoose runs the main query, collects the referenced IDs, and runs a separate query per populated path, essentially User.find({ _id: { $in: ids } }), then stitches the results together in Node. That's one extra round trip per path, not one per document, so it avoids N+1. But deep or nested populates add up, and you can't filter the parent by a populated field in the same query. For that, use an aggregation with $lookup, which does the join inside the database. Virtual populate covers the reverse side, like a user's posts, via localField and foreignField, without storing an array of IDs on the parent. lean() returns plain JavaScript objects instead of full Mongoose documents: no change tracking, getters, virtuals or save(), but much less memory and faster. I use it for read-only endpoints.

Question 33

A MongoDB-backed API has become slow. How do you find and fix the problem?

Accepted Answer

I work from evidence, not guesses. - Find the slow operations. The slow query log records operations over slowms, 100 ms by default, and the profiler (db.setProfilingLevel(1)) stores them in system.profile. db.currentOp() shows what's running now. On Atlas, the Query Profiler and Performance Advisor do this for you. - Explain them. Look for COLLSCAN, in-memory SORT stages and a poor ratio of keys examined to documents returned. Fix with compound indexes following ESR, and covered queries where possible. - Check memory. If the working set (hot data plus indexes) doesn't fit in the WiredTiger cache, reads hit disk. Look at cache eviction and page faults. - Check the schema. Bloated documents, unbounded arrays and $lookup on every read are design problems that indexes can't fix. - Check the client. Use one pooled client per process, project only needed fields, and batch writes with bulkWrite. - Check for redundant indexes with $indexStats; they slow writes. Only after that would I scale hardware or shard.

Question 34

What are the most common MongoDB schema and indexing anti-patterns?

Accepted Answer

The ones MongoDB itself warns about, and I see most:

Unbounded arrays: embedding comments, events or followers that grow forever. Documents bloat toward 16 MiB, updates rewrite big documents, and multikey indexes explode
Too many indexes: every index slows writes and competes for RAM. Drop unused or redundant ones; { a: 1 } is redundant if { a: 1, b: 1 } exists
Bloated documents: storing rarely used large fields with hot data, so every read pulls them into cache. Split them out with the subset pattern
Separating data that's accessed together: normalizing like SQL, then $lookup on every request
Massive numbers of collections, such as one per user or per day. Each collection and index has overhead
Case-insensitive regex queries like /^ana$/i, which can't use an index efficiently. Use a collation-based case-insensitive index instead

Also watch for deep skip() pagination and read-modify-write updates instead of atomic operators.

Question 35

What are the costs and limits of multi-document transactions, and how do you use them safely in production?

Accepted Answer

Transactions work, but they aren't free:

Time limit: a transaction must finish within 60 seconds by default (transactionLifetimeLimitSeconds), or it's aborted
Lock waits: it waits only 5 ms by default to acquire a lock before aborting
Write conflicts: if another operation modifies a document the transaction is writing, the transaction fails with a TransientTransactionError label and must be retried from the start
Cache pressure: open transactions pin old snapshots in the WiredTiger cache, so long ones hurt everyone
Sharded clusters: a transaction spanning shards uses a two-phase commit, which adds round trips and latency

Safe usage:

Keep transactions short and small; do reads and computation before starting
Use the callback API (withTransaction) so transient errors and UnknownTransactionCommitResult are retried
Make sure queries inside are indexed
Use w: "majority" for commits you can't lose
Prefer a single-document design when one is possible

A standalone server doesn't support transactions, and they can't write to capped collections or the admin, config and local databases.

Question 36

Compare hashed and ranged sharding. Which would you use for an events collection keyed by timestamp?

Accepted Answer

Ranged sharding splits data into contiguous ranges of the shard key. Documents with nearby keys live together, so range queries are targeted to few shards, and zones can pin ranges to regions. The weakness is a monotonically increasing key like a timestamp or ObjectId: every new document falls in the top range, so one shard absorbs all inserts while the balancer tries to catch up. Hashed sharding shards on a hash of one field. Nearby values scatter, so writes spread evenly even for monotonic keys, and equality queries are still targeted. The cost: range queries become broadcast to all shards, and hashed fields can't be arrays. For events keyed by time, I'd avoid a plain ranged { ts: 1 }. Options: - { deviceId: 1, ts: 1 } if most queries are per device: spread plus targeted, time-ordered reads - { _id: "hashed" } if writes dominate and queries rarely filter by time range - A compound key with one hashed field, like { tenantId: 1, ts: "hashed" }, to keep tenant-targeted queries while spreading inserts

Question 37

MongoDB is "schemaless". How do you enforce a schema on the server anyway?

Accepted Answer

MongoDB is really flexible-schema: by default documents in a collection can differ, but you can attach a validator that the server checks on every insert and update, whichever client writes. The usual tool is $jsonSchema, based on JSON Schema draft 4 with MongoDB extensions. bsonType checks BSON types like int, date or objectId; required lists mandatory fields; properties sets per-field rules like minimum, pattern and enum. You can also use query operators in the validator. Add or change rules on an existing collection with collMod. Two settings control strictness: - validationLevel: strict (default) checks all inserts and updates; moderate doesn't enforce rules on updates to existing documents that were already invalid, which helps when retrofitting rules onto old data - validationAction: error (default) rejects the write; warn allows it and logs the violation; recent versions add errorAndLog Existing documents aren't re-checked when you add a validator. Users with the right privilege can pass bypassDocumentValidation for migrations.

Question 38

What are change streams, and how do you make a consumer survive restarts?

Accepted Answer

Change streams give applications a real-time feed of data changes, built on the oplog, without tailing it by hand. You call watch() on a collection, a database or the whole deployment, and can pass an aggregation pipeline to filter or reshape events. They require a replica set or sharded cluster, and they only report changes committed to a majority, so you never see events that later roll back. Each event has an operationType (insert, update, replace, delete, invalidate and others) and documentKey. Updates carry only the changed fields unless you set fullDocument: "updateLookup", which fetches the current version of the document; that may include later changes. Since 6.0 you can enable pre- and post-images on a collection instead. For restarts, every event's _id is a resume token. Persist it after processing, and reopen with resumeAfter (or startAfter, which also works after an invalidate). Resuming only works while that point is still in the oplog, so size the oplog for your longest expected outage. Typical uses: cache invalidation, syncing a search index, notifications and event-driven microservices.

Question 39

What is a capped collection, and when would you use one instead of a TTL index?

Accepted Answer

A capped collection is a fixed-size collection that behaves like a circular buffer. You create it with db.createCollection("log", { capped: true, size: 100000 }), where size is in bytes and an optional max limits the document count. When it's full, the oldest documents are removed automatically to make room. It keeps documents in insertion order, so reading the newest entries is cheap, and it supports tailable cursors that stay open and stream new documents as they arrive, like tail -f. MongoDB's own replication oplog is a capped collection. Restrictions: capped collections can't be sharded, can't be written inside transactions, can't be the target of $out, and shouldn't be updated in ways that grow documents. With concurrent writers, insertion order isn't guaranteed. These days the manual generally recommends TTL indexes instead. Capped collections serialize writes, so they perform worse under concurrency, and TTL lets you expire by age rather than by total size. I'd choose capped only when "keep the last N megabytes" is exactly the requirement.

Question 40

How do you implement text search in MongoDB? What are the limits of a text index?

Accepted Answer

On self-managed MongoDB, create a text index, for example createIndex({ title: "text", body: "text" }, { weights: { title: 5 } }), then query with { $text: { $search: "coffee grinder" } }. The text index tokenizes strings, removes stop words and applies stemming for the chosen language, so "grinders" matches "grinder". The search string supports quoted phrases and -term to exclude. You can project and sort by relevance with { $meta: "textScore" }. Limits: - Only one text index per collection, though it can cover many fields, or all strings with "$" - No fuzzy matching, typo tolerance, autocomplete or partial-word matching - Relevance scoring is basic and hard to tune - Unanchored $regex isn't an alternative; it can't use an index efficiently For real search features, MongoDB recommends MongoDB Search (Atlas Search, built on Apache Lucene) with the $search stage: fuzzy matching, autocomplete, facets and custom analyzers, plus Vector Search** for semantic similarity.

Question 41

How do multikey indexes work, and what restrictions and performance traps come with them?

Accepted Answer

When you index a field that holds an array in any document, MongoDB automatically makes the index multikey: it stores one index entry per array element, all pointing to the same document. That's what makes { tags: "mongodb" } fast.

Restrictions:

In a compound multikey index, each document can have at most one indexed field that is an array. { tags: 1, categories: 1 } is fine until one document has both as arrays, and then that insert fails
A multikey index can't be a shard key index, and hashed indexes can't be multikey
It can't cover a query that returns the array field

Performance traps:

Index size grows with array length. A document with 5,000 tags adds 5,000 keys, and every push updates the index. That's another reason to keep arrays bounded
Bounds: for { scores: { $gt: 80, $lt: 85 } } without $elemMatch, different elements may satisfy each condition, so MongoDB can't simply intersect the bounds; it may scan a wider range. With $elemMatch, it can combine them into one tight range

Question 42

How do you optimize an aggregation pipeline? What does the optimizer already do for you?

Accepted Answer

The most important rule: only the start of a pipeline can use indexes, so put $match, and $sort when possible, first, and filter as early as you can. On a sharded collection, a leading $match on the shard key also targets fewer shards. The optimizer rewrites some things automatically: - moves $match filters ahead of $project, $addFields/$set or $sort when they don't depend on computed fields - coalesces $sort + $limit into a top-k sort, merges adjacent $match, $limit and $skip stages - folds $unwind (and a following $match) into a preceding $lookup - analyzes field dependencies so only needed fields flow through What I still do by hand: - Avoid $unwind + $group just to rebuild an array; use array operators like $filter, $map and $reduce - Index the foreignField of every $lookup - Keep an eye on the 100 MB per-stage memory limit; spilling to disk works but is slower - Precompute heavy reports with $merge into a summary collection - Check the result with explain() on the aggregate

Question 43

What does $facet do? How would you return search results, a total count and filter counts in one query?

Accepted Answer

$facet runs several sub-pipelines over the same input documents within a single stage. Each sub-pipeline's output becomes an array field in one result document. It's the natural fit for faceted search pages: one round trip returns the first page of results, the total count, counts per brand and price bands. Things to know: - The sub-pipelines are independent; one can't use another's output. Add stages after $facet to combine them - Sub-pipelines don't use indexes. Put a selective $match before $facet, which can use an index; a pipeline that starts with $facet does a collection scan - The combined output is a single document, so it must fit in 16 MiB, and each sub-pipeline stage has the usual 100 MB memory limit - You can't nest $facet or use stages like $out, $merge or $geoNear inside it For very large result sets, separate queries (or Atlas Search's $searchMeta for facet counts) may be cheaper.

Question 44

Explain replica set member configuration (priority, votes, hidden, delayed, arbiters) and when a rollback happens.

Accepted Answer

Member options shape elections and roles:

priority: higher-priority secondaries call elections sooner and are more likely to win; priority: 0 means the member can never become primary
votes: 0 or 1; at most 7 members vote, out of up to 50 total. Non-voting members must have priority 0
hidden: priority 0 and invisible to client reads; useful for backups or analytics
delayed: a hidden member applying the oplog after a set delay, giving a window to recover from something like an accidental drop
arbiter: votes but holds no data; it weakens durability and can make the default write concern w: 1

Elections use a Raft-like protocol: a candidate needs votes from a majority of voting members, and a primary that loses contact with a majority steps down.

A rollback happens when the old primary rejoins holding writes that never replicated to the new primary's side. Those writes are undone and saved as BSON files under dbpath/rollback for manual review. Writes acknowledged with w: "majority" are never rolled back.

Question 45

What are chunks, how does the balancer move them, and what is a jumbo chunk?

Accepted Answer

A chunk is a contiguous range of shard key values owned by one shard. The config servers store the mapping, and mongos uses it to route queries. The default range size is 128 MB. The balancer runs on the config server primary. In current versions it balances by data size per collection, not chunk count: a round starts when the gap between the shards with the most and least data for a collection reaches the migration threshold, about three times the range size (384 MB by default). Chunks are split when they need to be moved. A migration copies the documents to the recipient, catches up on changes made meanwhile, commits the new ownership on the config servers, then deletes the range from the donor asynchronously. Until cleanup, the donor's copies are orphaned documents. A jumbo chunk exceeds the range size but can't be split, because it holds a single shard-key value. It signals low cardinality or high frequency; refining the shard key is the real fix. A balancing window can restrict migrations to off-peak hours.

Question 46

How do you secure a MongoDB deployment?

Accepted Answer

I go through the manual's security checklist:

Enable access control. Self-managed MongoDB doesn't enforce authentication by default; set security.authorization: enabled. SCRAM is the default mechanism, with x.509 as an option, and LDAP and Kerberos in Enterprise
Least-privilege roles: create a user administrator first, then one user per app or person with only the roles it needs, such as read or readWrite on one database, or custom roles. No shared root accounts
Limit network exposure: mongod binds to localhost by default; if you widen bindIp, restrict it with firewalls, security groups or private networking. Never expose port 27017 to the internet
Encrypt: TLS for all traffic, including between members; encryption at rest; Client-Side Field Level Encryption or Queryable Encryption for sensitive fields
Auditing (Enterprise and Atlas), patching, and running mongod as a dedicated OS user

In application code, guard against operator injection: if a login handler passes req.body.password straight into a filter, an attacker can send { "$ne": null }. Cast inputs to expected types, or enable Mongoose's sanitizeFilter.

Question 47

What are the options for backing up MongoDB, and what are their trade-offs?

Accepted Answer

First, replication isn't a backup: an accidental deleteMany replicates to every secondary within seconds. The main approaches: - mongodump / mongorestore: a logical BSON export. Simple and portable, and the manual positions it for small deployments: it's slow on big datasets, indexes are rebuilt on restore, and it adds load. On a replica set, --oplog captures writes during the dump so mongorestore --oplogReplay restores a consistent point - Filesystem snapshots (LVM, EBS and similar): fast and suited to large data. Journaling must be on the same volume. For a sharded cluster you must stop the balancer and snapshot every shard and a config server at about the same moment - cp / rsync of data files: only with writes stopped - Managed backups: Atlas Cloud Backups, or Ops Manager and Cloud Manager, which take snapshots and support point-in-time recovery, including for sharded clusters Whatever you choose, define your RPO and RTO, and regularly test restores. A delayed hidden member can help you recover from human error, but it doesn't replace real backups.

Question 48

What is MongoDB Atlas, and what does it give you over running MongoDB yourself?

Accepted Answer

Atlas is MongoDB's fully managed cloud database service, running on AWS, Google Cloud and Azure. You choose a cluster tier, cloud and region, and Atlas deploys a replica set or sharded cluster for you. What you stop doing yourself: - Operations: provisioning, patching, version upgrades and scaling, including storage and compute auto-scaling - Backups: cloud snapshots with point-in-time restore - Monitoring: metrics, alerts, a Query Profiler and a Performance Advisor that suggests indexes - Security baseline: authentication required, TLS, encryption at rest and IP access lists or private networking It also bundles platform features that don't exist in a plain mongod: Atlas Search (Lucene-based full-text search), Vector Search, triggers, Charts, multi-region and multi-cloud clusters, and Online Archive for cold data. There's a free tier for learning (M0) and paid tiers from small shared clusters up to large dedicated ones. The trade-offs are cost at scale and less low-level control over the servers.

Question 49

What is Mongoose middleware? What is the bug in relying only on this pre("save") hook to hash passwords?

Accepted Answer

Middleware (hooks) are functions Mongoose runs before (pre) or after (post) an operation. There are four kinds:

Document middleware: validate, save, init and others, where this is the document
Query middleware: find, findOne, findOneAndUpdate, updateOne, deleteMany and so on, where this is the query, not a document
Aggregate middleware for aggregate()
Model middleware such as insertMany and bulkWrite

With an async function you don't need to call next(). Hooks must be registered before mongoose.model() compiles the schema.

The bug: save hooks don't run for updateOne, findOneAndUpdate and other query-based updates. That update goes straight to the database, so the password is stored in plain text. Fixes: load the document, set the field and call save(); or add a matching pre("updateOne") or pre("findOneAndUpdate") hook that hashes the value in the update; or route all password changes through one service method.

Question 50

Explain the bucket pattern. How does this update implement it for sensor readings?

Accepted Answer

The bucket pattern groups many small, related records into one document per bucket, usually per entity per time window, instead of one document per event. A sensor writing every second produces 86,400 tiny documents a day; bucketing turns that into a few hundred documents, with far fewer index entries, better compression and faster range reads.

This update appends a reading to the sensor's current bucket for the day, but only while count is under 200. When the bucket is full, the filter matches nothing and the upsert creates a new bucket. Its sensorId and day come from the filter's equality fields, while the $lt condition isn't copied. The bucket also keeps precomputed summary fields (count, sumTemp, first, last), so averages and ranges don't need to unwind the array. That's the computed pattern layered on top.

The count cap keeps arrays bounded. For time-series workloads, time series collections, available since 5.0, apply this bucketing internally, so today I'd try one of those first.

MongoDB interview questions & answers

Top 59 MongoDB interview questions most asked first