Design Indexes & the Query Engine

This is the read path of a document database drawn on its own. The documents already live in the collection as BSON records, and replication and sharding already decide which machine holds them. What is left is the part that turns a query into a small number of disk reads instead of a full scan. An index is a separate B-tree that maps values of a field to the documents that hold them. The query engine is the piece that looks at an incoming query, considers the indexes that could serve it, and picks one. Nothing here changes what the data is. It changes how few bytes you touch to answer a question about it.

Get the altitude right before drawing a box. This design sits below the driver and the router and above the storage engine. WiredTiger stores both the collection and the indexes as B-trees on disk and hands back pages; this layer decides which pages to ask for. The interesting judgment is not "add an index," which any developer types in a second. It is which indexes earn their keep, in what field order, and how the planner chooses among several that all technically apply. Get those wrong and you either scan the whole collection on every read or you slow every write down under the weight of indexes nobody's queries use.

The MongoDB angle

MongoDB sells itself as a developer data platform, and its promise is that a developer declares an index and queries feel fast without thinking about the machinery underneath. This round asks you to build the machinery. The interviewer very likely maintains the real query planner or the index code. A good answer uses the engine's vocabulary: a B-tree keyed on one or more fields, an IXSCAN that walks it, a FETCH that pulls the document, a plan cache keyed by query shape. Treat the index as a magic "make it fast" button and you have answered a question about using MongoDB rather than the question about building it, which is the one on the table.