1. Search indexing at scale

A seller on a secondhand marketplace lists a vintage leather jacket, switches to the buyer app, types "vintage leather jacket" into the search box, and sees nothing. Two seconds later the listing shows up. Nothing is broken. The search index is a separate copy of the listing data, split across many machines and fed from the main database a moment after each write. Search indexing at scale is how that copy gets split, queried, kept in sync, and made searchable.

This comes up whenever a design has a search box: marketplaces, social posts, tickets, logs. The interviewer asks how Elasticsearch stays consistent with the database, why a new post is not searchable yet, or what happens to latency at 100 shards. Be honest about the weight. It is usually a 5 to 10 minute deep dive, and many designs only need one line: "Elasticsearch, fed by change data capture from the database, about a second behind." At mid-level, know that line and why it is true. Senior candidates are expected to split the index, estimate tail latency, design the feed with ordering, and explain the refresh lag.

We will use one example throughout: a marketplace like Etsy or eBay with 400M listings in PostgreSQL. You should already know what an inverted index is. How text becomes terms (analyzers) gets only this sentence, and relevance ranking and typeahead are outside this tutorial. By the end, you can choose how to partition the index, bound the cost of querying every shard, feed the index without drift, rebuild it safely, and explain the gap between a write and a search hit.