Design Uber Eats

Reference Answer

For a full example answer with detailed architecture diagrams and deep dives, see our Design Yelp guide. The Yelp guide covers geospatial indexing, search infrastructure, and location-based discovery patterns that form the backbone of a restaurant delivery platform.

Also review the Search, Caching, and Message Queues building blocks for background on geospatial queries, cache invalidation strategies, and event-driven update pipelines.

Problem Statement

Design a food delivery marketplace that connects hungry customers with local restaurants. The platform must enable restaurant owners to register their establishments, upload menus with pricing and photos, define delivery zones, and manage operating hours. Customers should discover nearby restaurants through location-based search, filter by cuisine type or dietary preferences, view live availability and estimated delivery times, and browse detailed menus before placing orders.

Your system needs to handle peak dinner hours when millions of concurrent users search for restaurants in dense urban areas. Search results must appear in under 200 milliseconds and reflect real-time changes -- if a restaurant closes, pauses orders due to high volume, or updates its menu, those changes should propagate to user feeds within seconds. The discovery feed is the highest-traffic endpoint in your system, making caching and indexing strategies critical to success while maintaining data freshness.

Key Requirements

Functional

• Restaurant onboarding -- Allow restaurant partners to register with business details, upload menus with items and pricing, define delivery boundaries, and set operating schedules
• Location-based discovery -- Enable users to search for restaurants that can deliver to their address within a specified radius, filtered by cuisine type, price range, or dietary tags
• Real-time status display -- Show current restaurant state including open/closed status, current order volume, estimated preparation time, and dynamic delivery fees
• Menu browsing and search -- Support full-text search across restaurant names, cuisine categories, and individual dish names with ranked results

Non-Functional

• Scalability -- Handle 10 million restaurant searches per hour during peak periods with horizontal scaling
• Reliability -- Maintain 99.95 percent uptime for the discovery feed; gracefully degrade to cached results if live data is unavailable
• Latency -- Return search results in under 200 milliseconds at the 95th percentile; menu pages should load in under 500 milliseconds
• Consistency -- Eventually consistent model acceptable for menus and hours; strong consistency required for restaurant activation and deactivation

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Geospatial Search and Indexing Strategy

The core challenge is efficiently finding restaurants that can deliver to a user's location while applying multiple filters. Naive approaches using latitude/longitude calculations in a relational database will fail at scale.

Hints to consider:

• Consider using geohashing or S2 cells to partition the map into tiles and pre-index restaurants by region
• Evaluate dedicated geospatial search engines that combine location queries with full-text search in a single index
• Think about how delivery zones (polygons) differ from simple radius searches and how to validate point-in-polygon efficiently
• Discuss tradeoffs between accuracy and performance when dealing with irregular delivery boundaries

2. Caching Architecture for High Read Volume

The discovery feed serves orders of magnitude more reads than writes, with certain geographic areas (downtown districts) being exponentially hotter than others. Simple caching will not suffice given frequent updates to availability and pricing.

Hints to consider:

• Design a multi-layer caching strategy with different TTLs for static data (menus) versus dynamic data (open/closed status)
• Consider caching top-N restaurants per geohash tile to serve the most common queries without hitting the search index
• Plan for targeted cache invalidation when specific restaurants update status rather than invalidating entire regions
• Discuss how to handle cache stampedes when popular restaurants change state during peak hours

3. Event-Driven Updates and Data Freshness

Restaurant data changes frequently throughout the day -- operating hours shift, menus get updated, kitchens pause orders during rushes. These changes must propagate to the discovery feed without introducing race conditions or overwhelming downstream systems.

Hints to consider:

• Design an event streaming pipeline where restaurant services publish changes that consumers use to update search indexes and invalidate caches
• Consider partial document updates in your search index rather than full reindexing to minimize latency
• Think about ordering guarantees and how to handle out-of-order events for the same restaurant
• Discuss monitoring and alerting for data freshness to detect when the pipeline falls behind

4. Restaurant Onboarding Workflow

Bringing a new restaurant online involves multiple steps across different services -- geocoding addresses, verifying business licenses, processing menu uploads, generating search keywords, and activating payment processing. This is a classic distributed transaction problem.

Hints to consider:

• Model the onboarding process as a saga or workflow with compensating actions for each step
• Store workflow state durably so operators can resume failed onboardings or debug stuck processes
• Consider which steps can run in parallel versus which must be sequential
• Design for idempotency since external services may need to be retried
• Think about how to provide restaurant owners with visibility into onboarding progress

Suggested Approach

Step 1: Clarify Requirements

Start by confirming scope and constraints with your interviewer. Ask about expected scale -- how many restaurants and concurrent users? Clarify what "nearby" means -- fixed radius or dynamic based on delivery time? Understand update frequency for different data types -- how often do menus change versus open/closed status? Determine if you need to handle real-time order capacity or just static restaurant information. Confirm whether delivery zone boundaries are simple circles or complex polygons.

Step 2: High-Level Architecture

Sketch the major components: a Restaurant Service that owns restaurant profiles, menus, and operating hours with a PostgreSQL database as the source of truth; a Discovery Service that handles location-based search requests; a Search Index (Elasticsearch) optimized for geospatial and text queries; a Cache Layer (Redis) for hot geographic regions; and an Event Bus (Kafka) for propagating changes. Draw data flows for both the search path (user request to results) and the update path (restaurant changes to index updates).

Step 3: Deep Dive on Discovery and Search

Walk through how a user search works end-to-end. Explain your geospatial indexing choice -- Elasticsearch with geo_point fields and geo_distance queries combined with term filters for cuisine. Describe the caching strategy -- Redis storing top 50 restaurants per geohash tile with 5-minute TTLs for the full list and 30-second TTLs for status overlays. Detail the ranking algorithm that considers distance, rating, estimated delivery time, and restaurant availability. Discuss how you filter out ineligible restaurants before scoring to avoid wasted computation.

Step 4: Address Secondary Concerns

Cover the restaurant onboarding workflow using a state machine or saga pattern with durable execution. Explain how you would monitor data freshness by comparing timestamps between the source database and search index. Discuss scaling strategies -- sharding the search index by geography and adding read replicas for the restaurant database. Address consistency tradeoffs -- why eventual consistency works for menus but activation status needs stronger guarantees. Touch on observability -- tracking cache hit rates, search latency percentiles, and event processing lag.

Related Learning

Deepen your understanding of the patterns used in this problem:

• Yelp -- Geospatial search, point-of-interest discovery, and location-based ranking patterns
• Uber -- Real-time delivery logistics, driver matching, and ETA computation
• Search Systems -- Full-text and geospatial indexing fundamentals
• Caching -- Multi-layer cache design, geo-tile caching, and invalidation strategies
• Message Queues -- Event-driven update propagation and change data capture pipelines
• Databases -- Choosing between PostgreSQL, Elasticsearch, and Redis for different access patterns