Design a Phrase Search Service over Restaurant Reviews

Design a system that lets users search a large, growing collection of restaurant reviews by text. A query consists of one or more search strings, such as `chinese food`, and the system must find every review that contains them: for the query `chinese food`, it returns all reviews that contain `chinese food`. ```hint Do the work before the query arrives Scanning every review for each query does not scale. Think about what you can precompute when a review is written so that a query only touches reviews that could possibly match. ``` ```hint Two words are not a phrase Knowing which reviews contain `chinese` and which contain `food` is not enough to know which contain `chinese food`. Decide what extra information your precomputed structure has to keep. ``` ```hint Splitting across machines When that structure no longer fits on one machine, you can split it by review or by word. Work out what each choice does to a multi-word query and to the arrival of a new review. ``` ### Constraints and Clarifications - Assume the collection is too large to scan on every query, and that reviews keep being created, edited and deleted while queries run. - A review is free text plus metadata such as its restaurant, author, rating and creation time. ### Clarifying Questions - Does "contains `chinese food`" mean the exact phrase (both words adjacent and in that order), both words anywhere in the review, or a raw substring match in which `food` also matches inside `seafood`? - When several query strings are given, must a review contain all of them, or any of them? - Is matching case-insensitive, and should punctuation, plurals or misspellings still match (`Chinese-food`, `foods`)? - Does a query search all restaurants, or is it scoped to one restaurant, a city or another filter? - How many reviews exist, how fast do new ones arrive, and how soon must a new or edited review become searchable? - Should results be ranked by relevance, sorted by recency or rating, or returned in any order, and how should very large result sets be paged? ### What a Strong Answer Covers - A precise match definition (phrase, bag of words or substring, plus text normalization) settled before the design - An index built ahead of time, and exactly how a multi-word phrase query is evaluated against it - How the index is partitioned and replicated, how a query is fanned out and merged, and how very common words are kept cheap - An ingestion path that keeps the index in sync with review creates, edits and deletes, with a stated freshness target - Returning large result sets: a stable order, cursor-based pagination and caching of popular queries - Failure handling and rebuilds, plus the build-versus-buy trade-off against an off-the-shelf search engine ### Follow-up Questions - How would you support true substring matching, where `food` must also match inside `seafood`? - A query contains only very common words, such as `really good`. How do you keep it fast? - How would you rebuild the entire index after changing the tokenizer, without downtime? - The product later wants the most relevant reviews first instead of all matches in date order. What changes?