MongoDB · Intermediate interview

The aggregation pipeline processes documents through a sequence of stages, each transforming the stream and passing results to the next. Common stages: $match (filter), $group (aggregate with accumulators like $sum), $project (reshape fields), $sort, $limit, and $unwind (flatten arrays). It's MongoDB's tool for analytics and complex transformations, conceptually like a Unix pipe of operations.

db.orders.aggregate([
  { $match: { status: "paid" } },
  { $group: { _id: "$userId", total: { $sum: "$amount" } } }
]);

$lookup performs a left outer join to another collection within an aggregation, matching a local field to a foreign field and embedding the matched documents as an array. It brings join-like capability to MongoDB for cases where you've referenced data, but it can be expensive at scale — so heavy reliance on $lookup often signals data that might be better embedded for the access pattern.

Stages run in order, so filtering and shrinking the data early dramatically reduces work downstream. Put $match and $project (to drop fields) as early as possible so later stages process fewer, smaller documents, and so an early $match can use an index. Putting an expensive $group or $lookup before filtering wastes effort on documents you'll discard.

A compound index covers multiple fields in order, and prefix rules apply (it can serve queries on leading fields). The ESR rule guides field order: Equality fields first (exact-match filters), then Sort fields, then Range fields (like $gt). Following ESR lets a single index satisfy the filter and provide sorted results efficiently, avoiding in-memory sorts.

Beyond single/compound: multikey indexes automatically index array elements; text indexes enable keyword search; TTL indexes auto-expire documents after a time (great for sessions/logs); geospatial (2dsphere) for location queries; hashed indexes for hashed sharding; and partial/sparse indexes to index only some documents. You pick based on the data and query — for example a TTL index to auto-purge expired tokens.

A covered query is one where all the fields it needs (in the filter and the returned projection) are present in an index, so MongoDB answers it entirely from the index without reading documents — fast. To make a query covered you index the queried and returned fields and exclude _id in the projection if it's not indexed. explain() shows whether a query is covered (totalDocsExamined of 0).

One-to-many: embed the 'many' in the 'one' when bounded and accessed together (comments in a post), or reference by storing parent ids on the children when the many side is large or queried independently. Many-to-many: store arrays of references on one or both sides, or a separate linking collection — choosing based on which direction you query and how big the arrays get. Unbounded arrays are an anti-pattern (document growth, 16MB limit).

The bucket pattern groups many small time-series readings into documents per time window to reduce document count. The computed pattern stores precomputed aggregates to avoid recalculating on reads. The outlier pattern handles rare huge documents separately. The subset pattern embeds only the frequently-accessed slice and references the rest. These patterns optimize for read patterns and the 16MB document limit.

Embedding gives atomic single-document updates, so keep data that must change together in one document. When you reference or duplicate data across documents for read performance, you accept eventual consistency and must update copies (via application logic, background jobs, or change streams) — there's no automatic cascade. For operations spanning documents that need atomicity, multi-document transactions are available but should be used sparingly.

Single-document operations are always atomic. For atomicity across multiple documents/collections, MongoDB supports multi-document ACID transactions (on replica sets/sharded clusters), where you start a session, perform operations, and commit or abort. They're powerful but have overhead and locking costs, so the idiomatic approach is to model data so most operations are single-document and reserve transactions for genuine cross-document needs.

A replica set is a group of MongoDB nodes maintaining the same data: one primary that takes writes and secondaries that replicate from it via the oplog. If the primary fails, the set automatically elects a new one, providing high availability and failover. Secondaries can also serve reads (with a read preference), and the set is the foundation for durability and transactions.

Write concern controls how many nodes must acknowledge a write before it's considered successful — w:1 (primary only, fast but riskier) up to w:"majority" (durable across a majority, survives failover). Read concern controls the consistency/recency of data you read — e.g. "majority" returns data acknowledged by a majority (won't be rolled back). Together they let you tune the durability/consistency vs latency trade-off per operation.