Katkat

Design Uber Eats-style search function

UberSoftware Engineer · Onsite

Last updated

An Uber Software Engineer system design onsite question: design the search function for an Uber Eats-style food delivery platform, covering APIs, data ingestion, geo-aware indexing and retrieval, multi-stage ranking, real-time availability updates, scaling, caching, fault tolerance, monitoring, and freshness-vs-latency trade-offs. It tests the ability to build a low-latency, location-aware, highly available search system with strong observability.

Question

Design the search function for a large-scale food delivery platform similar to Uber Eats.

A user opens the app and types queries such as a restaurant name (e.g., "Joe's Pizza"), a cuisine (e.g., "Thai", "Sushi"), or a dish name (e.g., "cheeseburger", "pad thai", "vegan burger"). The system must return a ranked list of relevant restaurants (and possibly individual dishes) that can deliver to the user's location, taking into account relevance, restaurant availability, delivery distance, estimated delivery time, ratings, promotions, and business constraints.

Walk through the end-to-end design, covering the following parts:

  1. Requirements. State the functional requirements (search by restaurant name / cuisine / dish, location-aware results, only restaurants that can deliver to the user, filters such as open-now / price / rating / delivery-time, ranking by relevance + distance/ETA + popularity/rating + optional personalization) and the non-functional requirements (low latency such as P95 under ~200 ms from the service, high availability, freshness, and scalability to millions of users, hundreds of thousands of restaurants, and high QPS).
  2. User-facing search APIs. Define the search endpoint(s), request parameters (query, location, filters, pagination), and the response shape.
  3. Data ingestion and sources. Identify the source-of-truth systems the index draws from: restaurant profiles, menus, availability/inventory, pricing, logistics/ETA, ratings/reviews, promotions/ads, and user context. Distinguish slow-changing data from rapidly-changing data.
  4. Indexing and retrieval architecture. Describe the overall components, the search document model, the indexing pipeline, and how text, geo, and structured filters are supported.
  5. Query flow. Trace a request from the client through the gateway, the search service, candidate retrieval, hard filtering, dynamic-feature enrichment, ranking, and the paginated response.
  6. Ranking strategy. Explain how multiple signals are combined into a final ordering, and how this evolves from a heuristic weighted sum to a multi-stage machine-learned ranking pipeline. Address personalization.
  7. Handling real-time updates. Show how the system keeps results fresh when a restaurant closes, an item goes out of stock, a price changes, a delivery area changes, or ETA spikes due to demand.
  8. Scaling, caching, and fault tolerance. Cover sharding/replication, geo-partitioning, caching of availability-sensitive results, graceful degradation, and failure scenarios.
  9. Metric monitoring system. Design the observability layer that tracks search quality, reliability, latency, freshness, and business impact, including the instrumentation flow, dashboards, and alerts.
  10. Follow-up trade-offs. Discuss freshness vs. latency, exact (lexical) matching vs. semantic matching, and online ranking vs. precomputed ranking.