Distributed Search
A relational LIKE query doesn't scale to millions of records, doesn't rank by relevance, and doesn't tolerate a typo. Search systems are built to do all three.
Advanced
TopNotchNote
Notes that matter
why a normal database can't do this well
A customer searching PlateRoute for "sushi" expects results even if they typed "suishi," ranked by relevance, not a strict match. A relational database's
WHERE name LIKE '%sushi%' is a full table scan with no concept of relevance, typo-tolerance, or ranking — workable at small scale, hopeless once the catalog spans millions of items. Distributed search systems are purpose-built for exactly this: fast, fuzzy, ranked full-text lookup at scale.the inverted index: the core data structure
Instead of scanning every document for a match, a search engine pre-builds an inverted index — a mapping from each word to the list of documents containing it. A query becomes a fast lookup into this index instead of a scan across every record.
Documents:
doc1: "Tokyo Sushi Bar"
doc2: "Sushi Express"
doc3: "Tokyo Ramen House"
Inverted index:
"tokyo" -> [doc1, doc3]
"sushi" -> [doc1, doc2]
"ramen" -> [doc3]
"bar" -> [doc1]
Query "tokyo sushi" -> intersect [doc1, doc3] and [doc1, doc2] -> doc1 ranks highest
Building this index is itself work done ahead of time (at write time), which is exactly why search systems trade write speed for read speed — the opposite trade-off from a system optimized purely for fast writes.
fuzzy matching and relevance ranking
Beyond exact word matches, a good search index also handles typos ("suishi" → "sushi") via edit-distance matching, and ranks results by relevance rather than just returning every match unordered — commonly using a scoring formula like TF-IDF (how rare and how frequently a term appears) or more advanced ranking models layered on top.
architecture: the index is a derived copy, not the source of truth
| Component | Role |
|---|---|
| Primary database | Remains the durable source of truth for the underlying data (e.g. PlateRoute's actual restaurants table). |
| Indexing pipeline | Streams changes from the primary database (often via a message queue or change-data-capture feed) into the search index, asynchronously. |
| Search index (sharded) | The inverted index itself, sharded across nodes the same way any large dataset is (see Data Partitioning & Sharding Strategies) — often by document ID or a domain-specific key like restaurant region. |
| Query service | Accepts search requests, fans them out to the relevant shards, merges and ranks results. |
A crucial design decision: the search engine is not treated as durable primary storage, even though it holds a full copy of searchable fields. If the index is lost or corrupted, it can always be rebuilt by replaying from the primary database — this is what allows the indexing pipeline to be asynchronous (and therefore eventually consistent) without any real risk of permanent data loss.
consistency trade-off: search results can lag reality
Because indexing happens asynchronously, a restaurant that just updated its menu might not show the change in search results for a few seconds. This is a deliberate, usually acceptable trade-off — see Consistency Models — favoring write throughput and search performance over instant consistency, since a few seconds of staleness in search results rarely causes real harm.