Full-text search

Full-text search goes beyond `LIKE` or exact matches: text is analyzed into tokens, optionally stemmed or normalized, indexed in an inverted structure, and ranked by relevance signals (TF-IDF, BM25) plus business boosts and filters.

Pipeline mental model:

					raw text → analyzer → tokens → inverted index → query → score + highlight
				

Product features often need: prefix and fuzzy matching, synonyms, language-specific stemming, faceted filters (brand, price range), highlighting of matched terms, and pagination stable under concurrent writes.

PostgreSQL `tsvector` can suffice for moderate corpora; dedicated search engines add analyzers, distributed scale, and richer relevance tuning.

On interviews: walk through index-time vs search-time analysis, explain why the same query string can match differently than SQL substring search, and describe how filters interact with scoring.

Common pitfalls: indexing without the same analyzer used at query time; case-folding-only "search"; no synonym or typo strategy when users expect Google-like behavior; ranking purely by recency; exposing internal field names in public query DSL.

The trade-off is relevance quality and UX polish versus indexing complexity, language maintenance, and the need to evaluate search with real queries—not unit tests alone.

Checklist:

• Draw analyzer pipeline (tokenizer, filters).
• Contrast index-time vs query-time analysis.
• Name ranking inputs: BM25, boosts, filters.
• State when Postgres FTS is enough vs a search cluster.
• Mention evaluation: click-through, zero-result rate.