Design restaurant search and discovery (Zomato)

A naive design says 'find restaurants within 5 km'. Real delivery apps use delivery polygons, not circles: a restaurant across a river or a flyover with no U-turn may be 2 km away by air but 25 minutes by road. Each restaurant (or its zone) has a geo_shape polygon drawn from road-network travel time, and the query is 'polygons that contain the user's point'. Elasticsearch supports this with geo_shape queries backed by BKD trees; you can also precompute a mapping from H3 cell to the set of restaurants that serve it and store it in Redis, which turns the geo query into a key lookup. On top of the static polygon sits dynamic serviceability: in heavy Mumbai rain or when riders are short, logistics shrinks the effective radius per zone. That is why live zone state lives in a fast store and is applied at query time. In the interview, say clearly that relevance does not matter if the restaurant cannot deliver in 40 minutes, and that the system must never show a restaurant the user cannot order from.

Restaurant data changes at very different speeds. Name, cuisine and location change monthly. Menus and prices change daily. Open/closed, prep time and busy level change every few minutes, and at 8 pm thousands of restaurants change state each second. Writing every state change into Elasticsearch is a mistake: each update is a delete-plus-insert of the document, creates new segments, triggers merges and caches get invalidated, so search latency rises exactly at peak. The fix is two layers. Elasticsearch holds the slow-moving searchable fields, fed by CDC from the catalogue DB through Kafka with ~1-5 minute freshness. Redis holds live state keyed by restaurant_id, updated by events within a second. The query does retrieval in Elasticsearch, then a pipelined Redis read for a few hundred IDs (~1-2 ms), then filters. The same split lets you cache the expensive geo + text candidate list per H3 cell for 60 seconds while live filtering stays exact.

The goal of ranking is the probability that the user orders from this restaurant now and is happy with it. Use a two-stage approach. Retrieval gives ~300 serviceable candidates. A learning-to-rank model (gradient-boosted trees such as LightGBM, later maybe a two-tower plus re-ranker) scores them with features in four groups: query match (text score, dish match count), restaurant quality (rating, rating count, cancellation rate, order volume), context (ETA, distance, time of day, rain, offers active, delivery fee) and personal fit (cuisine affinity, veg preference, price band, ordered here before). Labels come from logs: impression -> click -> order. Business rules apply after the model: sponsored slots at fixed positions, clearly marked; a diversity rule so the top 10 is not all biryani places of one chain; a penalty for restaurants with high recent cancellations. Measure with A/B tests on orders per session and conversion, not click-through alone, because clickbait images raise clicks without raising orders.

Users type 'panir tika', 'chiken biriyani', 'dosa' vs 'dosai', or a Hindi word in Latin script. Plain English analysers fail here. Use several layers: a custom synonym and transliteration dictionary built from query logs (queries that led to the same orders are probably the same intent), fuzzy matching with edit distance 1-2 on longer tokens, phonetic filters, and edge n-grams for prefix search in typeahead. Index a normalised 'translit' field next to the original name. Query logs are the best source: if 'biriyani' searches usually end in orders for 'biryani' items, add the mapping. Also map dishes to cuisines and categories so that 'something spicy' or 'healthy' can fall back to tag search instead of zero results. Zero-result rate per city is a key metric to watch.

Elasticsearch gives text search, geo_shape, aggregations for filter counts and collapse in one system, and 30-60 GB of data is small for it. A custom in-memory index (H3 cell -> restaurant IDs) is faster for the feed. Common answer: use the H3 precomputation for the home feed and Elasticsearch for text search.

Precomputing a personal feed per user is wasteful because availability changes every minute and most users open the app only a few times a week. Compute on request, but cache the non-personal candidate list per H3 cell for ~60 s.

No query crosses cities, so per-city indexes (or routing by city_id) keep each query on one shard group, isolate a hot city (Bengaluru at dinner) and allow per-city analysers. Cost: more indices to manage.

CDC with a 1-5 minute lag is good enough for menus and prices; the checkout service re-validates the price at order time, so a stale search price never charges the user wrongly.

Traffic jumps 3-5x in an hour. Autoscale stateless search and ranking pods ahead of time on a schedule, keep Elasticsearch over-provisioned with replicas (it scales slowly), and raise the per-cell cache TTL from 60 s to 120 s under load.

Scoring 300 candidates with hundreds of features can take 30-50 ms. Batch feature fetches, keep the model small, and fall back to a simple heuristic score (rating x ETA penalty) when the ranker misses its deadline.

Search service has a timeout of ~50 ms on the ranker and falls back to a static popularity + ETA ordering. Users get a less personal list, not an error.

Fail safe, not open: treat state as unknown, show restaurants based on scheduled opening hours from the index, and let checkout re-validate. Alert loudly, because showing closed restaurants hurts conversion.

Kafka retains events, so the indexer catches up after a restart. Monitor consumer lag; menus may be a few minutes stale, which checkout validation absorbs.