Filters, Facets & Constraints

1. The Fundamental Split

Before diving into implementation, understand the three distinct concepts. They look similar in a UI but have very different performance characteristics. A well-designed search experience must handle all three correctly, or risk showing incorrect counts, slow responses, or confusing dead-ends.

Many junior engineers conflate these terms, leading to bugs like "why do facet counts not match results?" or "why is my filter so slow?" Each serves a distinct purpose: Filters exclude documents, Facets count values across results, and Constraints are the user-facing specifications that drive both.

2. Core Data Structures

Filters and facets rely on different data structures optimized for their specific access patterns. Understanding these is key to performance tuning.

3. Filter vs Query Context

In Elasticsearch/OpenSearch, clauses can run in "query" context (affects score) or "filter" context (binary, cacheable). This distinction is critical for performance—the same clause can be 10× slower in the wrong context.

Query context: When a clause participates in scoring, it must compute a relevance score for each matching document. This involves reading term frequencies, document lengths, and applying BM25 calculations.Filter context: Binary yes/no decision. No scoring, results cached as Roaring Bitmaps for reuse.

4. Faceted Navigation Architecture

Faceted navigation is the "refine your search" sidebar you see on e-commerce sites. It shows counts for each value, allowing users to drill down without hitting dead-ends. This is the feature that makes or breaks the search UX on sites like Amazon, Airbnb, or Netflix.

Computing facet counts requires reading every document in the result set and aggregating field values. This is CPU-intensive, which is why we use Doc Values (columnar storage) instead of the inverted index. The inverted index answers "which docs have term X?" but faceting needs "what values does doc X have?"—the inverse question.

5. The Post-Filter Pattern

The hardest part of faceted navigation is handling the interaction between selected facets and displayed counts. This is where most implementations go wrong—either showing incorrect counts or creating dead-end selections.

Consider: when user selects "Color: Red", what should the color facet show? If you filter first, you'd only see "Red (50)"— the user can't see alternatives! The correct behavior is:

• Results: Only red products (filtered by selection)
• Color facet: Still shows Blue (40), Green (20) so user can switch their selection
• Other facets: Only count within red products (combined filters apply)

6. Distributed Faceting Challenges

In a distributed index with multiple shards, facet counts become approximate. Each shard only sees its local data and returns its local top-N values. Review Chapter 3.6 for sharding architecture details.

This is the classic "scatter-gather" problem: the coordinator sends requests to all shards, each shard returns local results, and the coordinator merges them. For scoring, this works well because each document competes individually. For faceting, the counts must be summed across shards—but if a shard doesn't return a value in its top-N, that count is lost.

7. Performance Optimization

Filter and facet performance is dominated by I/O and cache efficiency. The key insight: filters run on immutablesegments, so caching is extremely effective. Understanding how to optimize both index-time schema decisions and query-time patterns can reduce latency by 10× on complex faceted queries.

Focus on two phases: Index-time decisions are permanent and affect all queries. Query-time optimizations can be applied per-query. Both matter, but index-time decisions have higher leverage.