Practice/Uber/Design Uber Eats

Design Uber Eats

System DesignMust

Problem Statement

Design a food delivery platform like Uber Eats that allows users to search for nearby restaurants based on location, radius, and cuisine type, while enabling restaurants to register and manage their listings. The core user journey is: pick a delivery location, see eligible restaurants with real-time status and ETAs, choose a menu item, and start an order.

The 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.

Interviewers at Uber ask this to test your ability to combine geospatial search, text search, real-time state, and high-read, low-latency feeds. They want to see how you balance accuracy (eligibility, hours, fees) with performance, handle frequent updates, and design robust onboarding workflows.

Key Requirements

Functional

Restaurant onboarding -- restaurant partners register with business details, upload menus with items and pricing, define delivery boundaries, and set operating schedules
Location-based discovery -- users search for restaurants that can deliver to their address within a chosen radius, filtered by cuisine, 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% uptime for the discovery feed; gracefully degrade to cached results if live data is unavailable
Latency -- return search results in under 200 ms at the 95th percentile; menu pages load in under 500 ms
Consistency -- eventually consistent model acceptable for menus and hours; strong consistency for restaurant activation/deactivation

What Interviewers Focus On

Based on real interview experiences at Uber and Meta, these are the areas interviewers probe most deeply:

1. Geospatial Search and Indexing Strategy

Efficiently finding restaurants that can deliver to a user's location while applying multiple filters is the core challenge. Naive approaches using lat/lon calculations in a relational database will fail at scale.

Hints to consider:

Use geohashing or S2 cells to partition the map into tiles and pre-index restaurants by region
Evaluate Elasticsearch for combining geo-distance 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 for irregular delivery boundaries

2. Caching Architecture for High Read Volume

The discovery feed serves orders of magnitude more reads than writes. 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)
Cache 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
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. These changes must propagate to the discovery feed without race conditions or overwhelming downstream systems.

Hints to consider:

Design an event streaming pipeline (Kafka) where restaurant services publish changes that consumers use to update search indexes and invalidate caches
Use partial document updates in Elasticsearch rather than full reindexing to minimize latency
Handle ordering guarantees and out-of-order events for the same restaurant
Monitor and alert for data freshness to detect when the pipeline falls behind

Practice/Uber/Design Uber Eats

Design Uber Eats

System DesignMust

Problem Statement

Key Requirements

Functional

Restaurant onboarding -- restaurant partners register with business details, upload menus with items and pricing, define delivery boundaries, and set operating schedules
Location-based discovery -- users search for restaurants that can deliver to their address within a chosen radius, filtered by cuisine, 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% uptime for the discovery feed; gracefully degrade to cached results if live data is unavailable
Latency -- return search results in under 200 ms at the 95th percentile; menu pages load in under 500 ms
Consistency -- eventually consistent model acceptable for menus and hours; strong consistency for restaurant activation/deactivation

What Interviewers Focus On

Based on real interview experiences at Uber and Meta, these are the areas interviewers probe most deeply:

1. Geospatial Search and Indexing Strategy

Hints to consider:

Use geohashing or S2 cells to partition the map into tiles and pre-index restaurants by region
Evaluate Elasticsearch for combining geo-distance 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 for irregular delivery boundaries

2. Caching Architecture for High Read Volume

The discovery feed serves orders of magnitude more reads than writes. 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)
Cache 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
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. These changes must propagate to the discovery feed without race conditions or overwhelming downstream systems.

Hints to consider:

Design an event streaming pipeline (Kafka) where restaurant services publish changes that consumers use to update search indexes and invalidate caches
Use partial document updates in Elasticsearch rather than full reindexing to minimize latency
Handle ordering guarantees and out-of-order events for the same restaurant
Monitor and alert for data freshness to detect when the pipeline falls behind