Why Search, and the Three Components
In one line: search decomposes into three components that run on completely different schedules. Recognizing that the crawler and indexer are offline while the searcher is online is the insight the whole chapter rests on.
Why search exists
Search bars are standard on modern websites because they allow users to filter vast amounts of content instantly. Without search, users would have to manually scroll through paginated lists — inefficient, and a poor user experience.
Consider platforms like YouTube or Google. With billions of videos and web pages, manual navigation is impossible. Search engines act as filters, retrieving relevant information from massive datasets in milliseconds.
'Milliseconds over billions of documents' is the constraint that forces everything else
Hold those two numbers together, because their ratio is the entire problem.
Scanning a billion documents at even a microsecond each would take 17 minutes. Users abandon at a few hundred milliseconds. So the system is roughly five orders of magnitude short of what brute force allows.
You cannot close that gap with faster hardware — you close it by not looking at most of the data. That is what an index is: a structure that lets you skip almost everything. Lesson 3 builds it.
And the remaining gap is closed by parallelism — splitting the index so many machines each search a small piece. Lesson 8 does that. The whole chapter is those two ideas.
The split that organises the whole chapter: the two halves run on completely different clocks, and every design decision is about moving work from the fast side to the slow one.
The three components
| Component | Role | Runs |
|---|---|---|
| Crawler | Fetches content and creates documents | Offline, continuously in the background |
| Indexer | Builds a searchable index — typically an inverted index — to organize data for efficient retrieval | Offline, in batches |
| Searcher | Executes queries against the index created by the indexer to return results | Online, on the user's critical path |
Note: we have a separate chapter dedicated to the crawler component. In this chapter, we focus on indexing.
The offline/online split is the most important structural fact in this chapter
Two of the three components are not on the user's critical path, and that changes everything about how you build them.
The searcher must answer in milliseconds. It is latency-critical, must be highly available, and scales with query volume.
The crawler and indexer can take minutes or hours. They are throughput-oriented, can fail and retry, and scale with corpus volume.
Those are different systems with different requirements, and Lesson 10 shows what goes wrong when you run them on the same machines: they contend for CPU and memory, and neither can scale independently.
It also buys something valuable — search results are allowed to be slightly stale. Lesson 12's availability argument leans on this directly: because indexing is offline, a search query never waits for indexing, and replication delay never blocks a user. Accepting staleness in the index is what makes the online path fast and available.
Notice what the searcher does beyond matching
The searcher parses the query, maps terms to the index, and returns ranked results — and it also handles spell correction and relevance ranking.
Matching is the easy part; an inverted index gives you the documents containing a term almost for free. The hard parts are the two extras:
Relevance ranking decides which of a million matching documents make the top ten. Lesson 4 shows the index stores term frequency and position precisely to support this, and Lesson 8's merger sorts on it.
Spell correction means the query the user typed may not be the query you search for — which is why Lesson 3 notes that fuzzy search significantly increases latency.
In an interview, saying "search is retrieval plus ranking, and ranking is the harder half" separates you from candidates who describe only the lookup.
Key takeaway
Three components: crawler and indexer run offline; the searcher runs online under strict latency. Milliseconds over billions of documents is five orders of magnitude beyond brute force, closed by indexing (skip most data) and parallelism (split what remains).
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | "A crawler collects data, an indexer indexes it, and a searcher answers queries." |
| L5 | Splits by schedule: "crawling and indexing are offline batch work; only the searcher is on the user's critical path, so those have completely different latency and availability requirements." |
| Staff+ | Names what the split buys: "because indexing is offline, search results are allowed to be slightly stale — and that's what makes the online path both fast and highly available, since a query never waits on indexing or replication. It also means the two should scale independently: the searcher scales with query volume, the indexer with corpus volume." |
Next: what we need to build, and how big it is.