Search Engine System Design
An interview-scoped walkthrough of how a search engine over a database-backed document corpus works — each subsystem built up from the naive first-pass answer to the scaled, production-shaped version, the way you'd actually talk through it in a room.
Minute one — before any subsystem
Scoping "Design a Search Engine"
"Search engine" spans keeping an index in sync with a database, ranking results, autocomplete, spell-check, personalization, ads — far too much for one session. An interview goes better with two: "I'll start here — build an inverted index from the documents already in our database, and serve a ranked query against that index. That's the whole pipeline in miniature. I'll name what's missing and expand into it once we've nailed this."
The core — say this first
- INDEX
background job — consumes changes from the databaseThe transform, and the discovery step in one. Turns documents already sitting in a database into the one structure — term → documents — that makes a query answerable in milliseconds instead of a full table scan. Indexing & the Inverted Index →
- GET
/api/search?q=...The read, and the hard problem. This one endpoint is what forces the ranking, latency-budget, and partial-result conversation — the centerpiece of the interview. Query Serving & Ranking →
Expand on later
Named up front so the interviewer knows you know they exist — detailed only once the core holds up, or if they ask. Each one is a real subsystem in this guide.
- Sharding the index
cross-cuttingSharding & the Distributed Index → - Caching
cross-cuttingCaching Layer → - Indexing backpressure
cross-cuttingIndexing Backpressure & Query Rate Limiting → - Autocomplete
GET /api/suggestAutocomplete & Query Suggestions →
Explicitly out of scope
- Ads & sponsored results — an orthogonal auction and billing system layered on top of ranking.
- Personalized ranking from user history — a separate signals pipeline, not the base relevance problem.
- Image, video, and geospatial search — different content types need different indexes entirely.
- Multi-tenant access control on documents — a separate authorization layer, not the base relevance problem.
Non-functional priorities
- Latency over freshness. A query has to return in well under a second; the index being a few seconds (or minutes) stale is usually fine — this asymmetry is why indexing and query serving can be built as separate systems with very different SLAs.
- Availability over completeness. Returning good-enough ranked results fast beats blocking on one slow shard to get a perfect answer — a search engine that occasionally omits one shard's results is fine; one that times out is not.
- The database stays the source of truth. The index is a derived, eventually-consistent projection of the database, not a second place data is written first — that's why CDC beats dual writes, and why backpressure on bulk indexing protects the cluster even when a burst of database changes arrives all at once.
How to open with this out loud: name the two core pieces of the pipeline before drawing a single box, say why each one earns its place, then rattle off the "expand on later" list in one breath — that's what signals you're scoping the problem deliberately, not stalling because you don't know where to start.
Core Data Flow
Scaling & Infra
Auxiliary Systems
Indexing Backpressure & Query Rate Limiting
How do you throttle bulk indexing so a write burst never overwhelms the search cluster, and protect the query API from abusive traffic?
Autocomplete & Query Suggestions
How do you suggest completions for a partial query fast enough to update on every keystroke?