Practice/Meta/Design Uber Eats

Design Uber Eats

System DesignMust

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% uptime for the discovery feed; gracefully degrade to cached results if live data is unavailable
Latency -- Return search results in under 200ms at the 95th percentile; menu pages should load in under 500ms
Consistency -- Eventually consistent model acceptable for menus and hours; strong consistency required for restaurant activation/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 won't 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

Practice/Meta/Design Uber Eats

Design Uber Eats

System DesignMust

Problem Statement

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% uptime for the discovery feed; gracefully degrade to cached results if live data is unavailable
Latency -- Return search results in under 200ms at the 95th percentile; menu pages should load in under 500ms
Consistency -- Eventually consistent model acceptable for menus and hours; strong consistency required for restaurant activation/deactivation

What Interviewers Focus On

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

1. Geospatial Search and Indexing Strategy

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

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

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