How do you return Atlas Search facet counts alongside the matching documents?

## What faceting is for Faceted navigation is the sidebar on a search results page: brand (Acme 42, Globex 17), price bands, publication year. Computing it means asking, for the *current query*, how many matching documents fall into each bucket — a question about the whole result set, not the page of ten documents you are showing. Atlas Search computes this inside `mongot`, where the matching set already lives, instead of making you re-aggregate the collection. ## The index side Facets need dedicated structures, so the path must be declared in the search index definition with a facet type: `stringFacet`, `numberFacet` or `dateFacet`. A field mapped only as a searchable `string` cannot be faceted, and asking for it produces an error rather than an empty facet. A field frequently needs both mappings — one variant to search on, one to facet on — which the `multi` option or a two-entry array in the `fields` block provides. ## The query side, option one: $searchMeta `$searchMeta` takes the same argument shape as `$search` but returns a single metadata document instead of matching documents. It is the right call when the client only wants counts: a result-count badge, a facet sidebar refreshed independently of the result list, or a "did this filter combination find anything" probe. Because no documents are fetched from `mongod`, it avoids the id-then-lookup round trip entirely. Its `count` option controls how the total is computed: `{ count: { type: "total" } }` returns an exact count, while `{ count: { type: "lowerBound", threshold: N } }` counts exactly up to a threshold and reports a lower bound beyond it. That distinction matters at scale, because exact counting over a huge match set is real work — the same reason web search engines say "about 4,000,000 results". ## The query side, option two: the facet collector When one round trip should return both the page of results and the facet buckets, use the `facet` collector inside `$search`. Its shape is: ```javascript { $search: { index: "default", facet: { operator: { text: { query: "laptop", path: "title" } }, facets: { brandFacet: { type: "string", path: "brand", numBuckets: 10 }, priceFacet: { type: "number", path: "price", boundaries: [0, 500, 1000, 2000] } } } } } ``` The `operator` key holds the query that would otherwise be the whole `$search` argument, and each entry in `facets` names a bucket set. String facets take `numBuckets` (how many top values to return); number and date facets take explicit `boundaries` plus an optional `default` bucket for values outside them. Matching documents continue down the pipeline normally, so `$limit`, `$project` and `$sort` work as usual. The metadata arrives through the **`$$SEARCH_META`** system variable, readable in any later stage — typically attached once with a `$set`/`$facet` combination, or read by a `$group` that emits a single response envelope. Because it is a query-level variable, not a per-document field, referencing it inside `$project` on every document duplicates the same object onto each result; most applications instead run a `$facet` whose one branch pages the documents and whose other branch emits `$$SEARCH_META` once. ## Operational notes Facet counts describe the mongot index, so they inherit its eventual consistency: a document written a moment ago may not yet be counted. On sharded collections `$$SEARCH_META` has restrictions, so validate the pattern against your topology before relying on it. And facets over very high-cardinality string fields are expensive — `numBuckets` caps what is *returned*, not the work of ranking the values, so faceting on something like a free-text field is a design error. ## What to say in an interview Name both stages, state that the facet path needs a facet mapping in the index definition, and explain the `$$SEARCH_META` variable as the channel through which query-level metadata reaches later stages. Mentioning `lowerBound` counting shows you have thought about the cost of exact counts.