Case study: Full-text search engine

When a search coordinator scatters a query to 64 index shards in parallel and waits for all of them, what determines the query's response time?

A query fans out to 64 independent shards. Each shard finishes under 50 ms 99% of the time. Roughly what fraction of uncached queries see at least one shard take longer than 50 ms?

Why do index shards return only `(docId, score)` in Phase 1 instead of returning full titles and text snippets immediately?

Why do large search engines partition the inverted index by document ID rather than by term?

Why do search engines write new documents into immutable index segments rather than updating posting lists in place?

How does splitting the index into a small high-PageRank 'Tier 1' in RAM and a huge 'Tier 2' on NVMe reduce cost?

During a background segment merge, one replica of shard 12 experiences 80 ms latency spikes while its peer replica is idle. Which mechanism masks this spike from the user?

One of 64 index shards is unreachable during a network blip, and the coordinator's 150 ms soft deadline fires with 63 of 64 shards having responded. What should the search engine return?