Exercise 3: Tracing the Combined Query Back to Its Underlying Mechanisms — Possible Solution ==================================================================== THE RANKED RESULTS: BM25 SCORING VIA THE INVERTED INDEX ------------------------------ Per this chapter's own "Why This Works" section, "the ranked results come from BM25 scoring (search1-6) computed via the inverted index (search1-4)." When the capstone's own multi_match clause searches "wireless mouse" against the name and description fields, it isn't scanning raw text — per search1-4's own material, each field's own content was already broken into individual terms and stored in an inverted index (term → list of documents) at index time. The search looks those terms up directly in that structure. Once matching documents are found, per search1-6's own material, BM25 computes each document's own relevance score using term frequency (weighted down for common terms, up for rare ones, per TF-IDF's own foundational logic), with term-frequency saturation and field-length normalization refining that raw score further — and the capstone's own name^3 boosting multiplies the contribution of matches found in the name field specifically, per search1-6's own boosting material. THE FACET COUNTS: AGGREGATIONS COMPUTED IN PARALLEL ACROSS SHARDS ------------------------------ Per this chapter, "the facet counts come from aggregations (search1-7) computed in parallel across shards (search1-8)." The capstone's own by_category, by_brand, and price_ranges aggregations are bucket aggregations, per search1-7's own material — grouping the same filtered set of matching documents by distinct field values or numeric ranges. Per search1-8's own material, the actual product index is physically split into multiple shards, each an independent Lucene index, potentially living on different nodes. Computing these aggregations doesn't mean scanning the whole dataset on one machine — each shard computes its own partial aggregation result in parallel, and those partial results are then combined into the final combined counts returned in the response. WHY THE WHOLE REQUEST EXECUTES FAST AT SCALE ------------------------------ Per this chapter, "the whole request executes as fast as it does specifically because of the distributed, parallel architecture search1-8 covered." Both the search-and-score work and the aggregation work benefit from the exact same underlying mechanism: splitting the total workload across multiple shards/nodes and running those pieces simultaneously rather than sequentially on one machine. This is precisely why a single request combining full-text search, relevance ranking, filtering, AND multiple aggregations can still return quickly even against a genuinely large product catalog — the distributed architecture from search1-8 is the structural reason none of the other, more sophisticated per-request work (BM25 scoring, nested aggregations) becomes a real performance bottleneck at scale. WHY THIS WORKS AS AN ANSWER ------------------------------ It traces both major parts of the response (ranked results, facet counts) back to their own specific named mechanisms from earlier chapters, using the chapter's own wording, and explains why the distributed architecture specifically is what keeps the whole combined operation fast, rather than describing each piece as an isolated feature.