MongoDB · Advanced interview

Sharding distributes a collection across shards by the shard key, and the key choice is the most important and hardest-to-change decision. A good key has high cardinality, even write distribution, and aligns with your common queries so they target a single shard. A poor key (e.g. monotonically increasing like a timestamp or ObjectId) creates a hot shard taking all writes, and a low-cardinality key can't spread data — both undermine the whole point of sharding.

Ranged sharding splits data into contiguous key ranges (chunks), which keeps range queries efficient and co-locates nearby keys but risks hotspots if the key is monotonic. Hashed sharding hashes the key to distribute writes evenly, avoiding hotspots, but range queries become scatter-gather across shards. You pick ranged when range queries dominate and the key spreads well, hashed when you need even write distribution and queries are mostly point lookups.

A targeted query includes the shard key, so the router (mongos) sends it to just the shard(s) holding that data — efficient and scalable. A scatter-gather query lacks the shard key, so it must be broadcast to all shards and the results merged — slower and less scalable as you add shards. Designing queries to include the shard key is essential to getting sharding's benefits.

Secondaries replicate by tailing the primary's oplog (a capped collection recording every write operation idempotently) and applying it. If the primary becomes unreachable, the remaining nodes hold a Raft-like election — a majority must agree on a new primary, which is why odd-numbered sets and an arbiter/majority matter to avoid ties and split-brain. Replication lag is how far behind a secondary's oplog application is.

Read preference routes reads to the primary (primary/primaryPreferred) or secondaries (secondary/secondaryPreferred/nearest). Reading from the primary gives the most current data; reading from secondaries scales reads but can return stale data due to replication lag. Combined with read concern (e.g. majority), you tune the freshness/consistency vs load trade-off — analytics might tolerate secondary reads, while read-your-writes needs the primary or causal consistency.

When the primary fails, there's a brief window with no primary until an election completes, during which writes error or are retried (the drivers' retryable writes help). Writes acknowledged only by the old primary but not replicated to a majority can be rolled back when it rejoins as a secondary — which is why majority write concern matters for durability. Applications should handle transient errors and use retryable writes plus appropriate write concern.

Use explain() to see if stages use indexes. Move $match and $project to the front so an index filters early and less data flows downstream; ensure the initial $match is index-supported; avoid unnecessary $lookup and $unwind on large data; and watch for in-memory sorts/groups exceeding limits (they spill or fail without allowDiskUse). Often the fix is an index that supports the leading $match/$sort, or reshaping the schema to avoid the heavy stage entirely.

The working set is the data and indexes actively accessed. WiredTiger (the storage engine) caches data in memory; if the working set fits in RAM, reads are fast, but once it exceeds memory, MongoDB pages from disk and performance degrades sharply. So you size memory to the working set, keep indexes small enough to stay resident, and shard to spread the working set across machines when it outgrows one node.

Use explain("executionStats") to see the winning plan, index usage, documents examined vs returned (a big ratio signals a missing index), and whether sorts are in-memory. The database profiler logs slow operations to system.profile, and tools like mongotop/mongostat and Atlas's performance advisor surface hotspots. You target queries scanning far more documents than they return by adding the right index or covering the query.

Causal consistency, provided within a client session, guarantees that operations respecting a causal order (read-your-writes, monotonic reads/writes) are observed in that order even across primary and secondaries. It lets you read from secondaries while still seeing your own prior writes, by tracking operation/cluster times. It's a middle ground between strong consistency (primary, majority) and unordered eventual reads.

Change streams let applications subscribe to a real-time feed of data changes (inserts/updates/deletes) on a collection, database, or deployment, built on the oplog and resumable after disconnects. They're used for event-driven architectures, cache invalidation, syncing to other systems (search indexes, analytics), and notifications — replacing fragile oplog tailing with a supported API.

Multi-document transactions hold locks and accumulate oplog/journal overhead, can abort under write conflicts (needing retry logic), and have time/size limits — so they don't scale like single-document writes. You avoid them by modeling data so related fields that must change atomically live in one document (leveraging atomic single-document updates), and reserve transactions for genuine cross-document invariants. Over-reliance on transactions usually signals a relational-style schema that fights the document model.