Uber System Design Interview: Design Uber Eats Search

Overview

You are asked to design the search system for Uber Eats so users can find restaurants and dishes by keywords, cuisine, or location. The system must serve mobile and web clients globally, return relevant results within 200ms (95th percentile), maintain 99.9% uptime, scale to millions of daily queries, and reflect updates within a few minutes.

What you'll be asked to do

You should clarify query types (restaurant vs. dish vs. autosuggest), geographic scope (city vs. country), freshness requirements for availability/menu changes, and personalization depth. Then propose an architecture: ingestion (CDC + message bus), indexing (inverted index / OpenSearch or Elasticsearch), geo-aware sharding/replication, query service with ranking and personalization, and caches at region edge.

High-level flow/stages

1. Clarify requirements and SLAs.
2. Data model & indexing strategy: documents for restaurants and menu items, faceted fields for filters.
3. Ingestion pipeline: transactional DB -> change stream -> Kafka -> indexer (near-real-time).
4. Query path: API gateway -> regional query nodes -> cache -> ranked results with geo-filter & personalization.
5. Operational concerns: monitoring, rate limiting, blue/green index rollouts, and A/B testing of ranking.

Skills & signals you should show

Demonstrate knowledge of inverted indices, geo-queries and geospatial indexing, sharding/replication strategies, consistency vs. freshness trade-offs, low-latency caching, and personalization (feature signals or learning-to-rank). Discuss scaling, failure modes, and measurable trade-offs (cost vs. latency vs. freshness).