Design a Full-Text Search Service

Design a full-text search service that indexes a large, continuously changing document corpus and answers keyword queries with ranked results (think the search box behind a large e-commerce catalog or a code-hosting site). Clients submit free-text queries and expect the most relevant documents back, fast, while writers stream document creates, edits, and deletes into the same system.

Operating context. The corpus holds roughly 2 billion documents averaging 4 KB of indexable text each (about 8 TB of raw text, far more than one machine's index can hold). Query traffic is read-heavy and spiky: 20,000 queries/sec at steady state, bursting to 80,000/sec during promotions, with a p99 end-to-end budget of 200 ms. Writes arrive as a change stream at about 15,000 document mutations/sec; freshly written documents should become searchable within a few seconds, not hours. Query terms follow a heavy Zipf skew, so a small set of terms and documents are extremely hot.

Out of scope. Query-language parsing beyond simple AND/OR/phrase, spell-correction and query autocomplete, personalization and per-user access filtering, the crawler/connectors that produce the change stream, and any ML-learned ranking model training. Assume a separate team owns those and hands you a clean mutation stream.

What to produce. A high-level architecture covering: the inverted-index data model and how postings are stored; how the index is sharded and replicated across nodes; the ingestion/indexing pipeline that turns the mutation stream into searchable segments; the query path — how a query fans out to shards, how partial results merge, and how the top-K is assembled; the relevance-ranking approach; and the near-real-time vs batch trade-off for making new writes visible. Sketch the major components and the request flow for both a query and a write; we will probe specifics at checkpoints.