Design Personalized Restaurant Search
Turn a food query into a personalized list of eligible restaurants, with a bounded role for an LLM, a reliable fallback, and a ranker that can be trained and tested online.
Problem statement
Design personalized restaurant search: a user enters a food query and receives restaurant recommendations. Explain how an LLM could improve this service. For this exercise, assume a signed-in user supplies a query and an approximate delivery location.
Return up to 20 open restaurants that can serve that location, using the user’s permitted preferences when available. Operators publish restaurant details, opening state and service areas. Record consented impressions and actions so a ranking change can be evaluated.
For this exercise, also assume all restaurants in a delivery area draw on one shared pool of couriers, so a change that shifts or adds orders in an area can change delivery times for every customer there.
The LLM may help understand a query or represent restaurant text, but it must not invent restaurants or their current eligibility. A conventional search path must remain usable if the LLM path is late, invalid or unavailable. Restaurant ordering, payments and route planning are outside scope.
All detailed requirements, counts and deadlines below are practice assumptions.
What to build
- A user receives up to 20 restaurants relevant to a food query, permitted preferences and the approximate delivery location.
- Operators can update restaurant details, opening state and service areas; restaurants known to be closed or unable to serve the location are omitted.
- Record consented result impressions and actions with request and decision versions so ranking changes can be evaluated.
- Use one justified role for an LLM while preserving the same restaurant eligibility boundary, response deadline and conventional fallback.
At scalePractice assumption
- One million active restaurants and 10000 search requests per second at peak; first-page p 95 latency must stay below 300 ms.
- Restaurant updates peak at 1000 per second, and an accepted closure or service-area change must affect new responses within 60 seconds.
- An expensive ranker may examine at most 500 retrieved candidates for a request, and responses contain at most 20 restaurants.
- User preference data are opt-in; a request may use approximate location, but raw queries and precise locations are excluded from general-purpose logs.