Exercise 3: Why Combining match and filter Is a Realistic, Common Pattern — Possible Solution
====================================================================

THE WORKED EXAMPLE
------------------------------
Per this chapter's own worked example:

  POST /products/_search
  {
    "query": {
      "bool": {
        "must": [
          { "match": { "description": "wireless mouse" } }
        ],
        "filter": [
          { "range": { "price": { "lte": 50 } } },
          { "term": { "category": "electronics" } }
        ]
      }
    }
  }

WHAT REAL-WORLD SCENARIO THE match CLAUSE SERVES
------------------------------
The match clause — searching description for "wireless mouse" —
serves the genuine, open-ended search intent: a shopper typed
something into a search box, and the application wants to find and
RANK products by how well they actually match that search phrase, per
this chapter's own explanation that match "contributes to relevance
scoring." Some products' descriptions might mention "wireless mouse"
prominently and repeatedly; others might mention it only in passing.
The match clause is what lets genuinely better textual matches surface
higher in the results — exactly the open-ended, fuzzy "find things
related to what the user typed" problem full-text search exists to
solve.

WHAT REAL-WORLD SCENARIO THE filter CLAUSES SERVE
------------------------------
The two filter clauses — price <= 50 and category = "electronics" —
serve a completely different, genuinely common real-world need: a
shopper narrowing results using structured, exact facets (a price
range slider, a category dropdown) on an e-commerce site. These
conditions are binary yes/no criteria with no meaningful notion of
"how well" a product satisfies them — a product's price either IS at
or below $50 or it isn't, and it either IS in the electronics category
or it isn't. Per this chapter's own earlier explanation, these are
exactly the kind of conditions that belong in filter rather than must,
since they shouldn't influence how strongly a product is RANKED, only
whether it appears in the results at all — and per the chapter, filter
clauses are also "more cacheable and efficient" precisely because they
don't need to be re-scored for every query.

WHY COMBINING BOTH IN ONE QUERY IS GENUINELY COMMON, NOT A SPECIAL CASE
------------------------------
This exact pattern — one open-ended text search combined with several
structured, exact filters — is close to the DEFAULT shape of a real
product-search or e-commerce search feature: users routinely both type
a free-text search term AND apply structured filters (price, category,
brand, in-stock status) at the same time, expecting the results to be
both textually relevant to their search AND constrained to match their
selected filters. This is exactly why the chapter frames this worked
example as "directly previewing search1-11's own capstone" — a real
product-search feature genuinely needs both the must clause's own
relevance-ranking capability and the filter clauses' own exact,
efficient narrowing, working together in the same query.

WHY THIS WORKS AS AN ANSWER
------------------------------
It identifies the specific real-world purpose of the match clause
(open-ended, ranked text search) and the filter clauses (structured,
exact, non-scoring narrowing) individually, using the chapter's own
worked example and its own must-vs-filter reasoning, and explains why
combining both reflects a genuinely common real search-feature shape
rather than an artificial demonstration.