Search & Indexing (Inverted Index)

Storage

Purpose-built indexes (inverted index, B-trees) that make full-text search and complex filtering fast at scale.

Relational DB indexes (B-trees) are great for equality/range lookups on structured columns, but terrible at full-text search ('find documents containing these words, ranked by relevance'). Search engines (Elasticsearch/OpenSearch, Solr, built on Lucene) build an inverted index: a mapping from each distinct term to the list of documents containing it, enabling fast keyword lookup, relevance ranking (TF-IDF/BM25), faceting, and fuzzy/typo-tolerant matching.

How it connects

Search & Indexing (Inverted Index) as the source, with the components it typically interacts with.

→ Database Types (SQL, NoSQL & Beyond): The primary database remains the source of truth while a search index (Elasticsearch) is built from it to serve full-text/fuzzy queries efficiently.
→ Message Queues & Event Streaming: Database changes are streamed through a queue (CDC) to keep the search index eventually consistent with the source of truth.
→ Caching: Hot search queries are cached in front of the index to avoid re-scoring/re-executing the same expensive query repeatedly.

Often used alongside

Database Types (SQL, NoSQL & Beyond)Message Queues & Event Streaming Caching