Search Indexes (Elasticsearch)

Databases are bad at "find documents containing these words." A query like LIKE '%storm%' cannot use a normal B-tree index — the index is sorted by how strings start, and this term could appear anywhere — so the database scans every row.

An inverted index flips the layout: instead of mapping each document to its words, it maps each word to the list of documents containing it. In the animation, documents flow into a grinder that tokenizes them — chops them into individual words. Each word then files itself into an index-card cabinet, and each card lists the IDs of every document that word appears in.

Then watch a search: a two-term query pulls two cards, animates the intersection of their document lists — only the documents on both cards match — and returns results ranked by relevance. That intersection of two pre-built lists is why full-text search is instant when a table scan is not.

The standard architecture, and the interview answer: keep the source of truth in your database and sync changes into Elasticsearch (the standard inverted-index search engine) via change data capture — a pipeline that streams every database change to the index. Search results run slightly behind the database, and for search, that staleness is fine.