Design Restaurant Listing and Ranking

Problem Design the restaurant listing a user sees when they open a food-delivery app: which restaurants are shown, in what order, and how availability and delivery radius are respected. The prompt is deliberately open-ended and under-specified.

Functional requirements

• Given a user location, return nearby serviceable restaurants.
• Rank results by relevance (distance, rating, personalization, business rules).
• Filter by cuisine, price, rating, veg/non-veg, offers.
• Exclude or deprioritize restaurants that are temporarily closed, outside the delivery radius, or out of stock.
• Support sponsored/promoted placement alongside organic ranking.
• Reflect an availability toggle (restaurant goes offline) quickly.

Non-functional requirements

• ~20M DAU; the listing is the app's landing screen → ~50k QPS at peak, the highest-traffic surface in the product.
• ~500k restaurants nationally; a typical query considers ~500-2,000 candidates within a serviceable radius.
• Listing p99 < 300 ms end-to-end.
• Availability toggle must propagate in < 30 s — showing a closed restaurant is a wasted order and a support ticket.
• Cache hit rate > 80% for dense metros; the location key space is the challenge.

Key components

• Retrieval stage: geo-indexed restaurant store (geohash / S2 / R-tree / quadtree) returning candidates within the serviceable radius, filtered by hard constraints (open now, serves this address).
• Ranking stage: scores candidates on distance, ETA, rating, conversion history, personalization signals (past orders, cuisine affinity), and business rules (sponsored slots blended in at fixed positions).
• Feature store supplying user and restaurant features to the ranker at request time.
• Availability service: the source of truth for open/closed/busy state, pushed to the retrieval layer rather than polled.
• Cache: per-geo-cell result cache for popular areas, keyed on (cell, filters, user segment) rather than exact lat/long.
• Offline pipeline computing restaurant-level aggregates (rating, historical prep time, popularity) consumed by the ranker.

Deep dives / trade-offs

• Scoping the ambiguity: the first move is to clarify the objective — is the listing optimizing for conversion, GMV, discovery of new restaurants, or delivery efficiency? Those produce materially different rankers. Then pin down whether sponsored placement is fixed-slot or auction-based.
• Retrieval vs ranking split: retrieval must be cheap and recall-oriented over 500k restaurants; ranking can be expensive over ~1k candidates. Discuss why you never rank the whole corpus.
• Cache key design: caching on exact lat/long gives a ~0% hit rate. Snapping to a geo-cell gives high hit rates but users at a cell boundary see subtly wrong ETAs, and personalization defeats caching entirely — so cache the retrieval stage and personalize on top.
• Real-time availability without stale listings: a restaurant toggling offline must not linger. Push-based invalidation into the cache vs a short TTL vs filtering at read time against a fast availability store — compare the staleness/complexity/latency trade-offs.
• Ranking vs business rules: sponsored placement directly conflicts with relevance. Discuss capping sponsored slots, quality floors for promoted restaurants, and measuring the long-term retention cost against short-term ad revenue.
• Cold start: a brand-new restaurant has no conversion history and will never rank, so it never gets any. Explicit exploration budget is the standard answer.

What's evaluated How you scope an intentionally ambiguous problem — clarifying constraints and objectives before designing, and stating your assumptions explicitly rather than jumping to a diagram.