Design Uber

Problem Statement

Design a food delivery platform similar to DoorDash or Uber Eats that connects hungry customers with local restaurants and manages a fleet of delivery drivers. The system must handle the complete ordering flow: browsing menus, placing orders, routing them to restaurants for preparation, dispatching nearby drivers to pick up food, and delivering it to customers while providing real-time tracking throughout the journey.

The platform operates in dozens of cities with thousands of concurrent orders during peak meal times. Customers expect accurate ETAs, live location tracking, and seamless payments. Restaurants need reliable order notifications and kitchen display integration. Drivers require efficient routing, batch pickup opportunities, and fair work assignment. The interviewer wants to see how you balance low-latency matching, eventual consistency across services, handling failed deliveries, and maintaining accurate inventory as menu items sell out.

Key Requirements

Functional

• Order placement -- customers browse restaurant menus with real-time availability, add items to cart, apply promos, and submit orders with delivery instructions
• Restaurant fulfillment -- restaurants receive order notifications, confirm acceptance, update preparation status, and mark orders ready for pickup
• Driver dispatch and routing -- system assigns orders to available drivers based on proximity and capacity, provides navigation, and supports multi-order batching
• Real-time tracking -- customers and restaurants see live driver location, updated ETAs, and order status changes throughout the delivery lifecycle
• Payments and payouts -- platform processes customer payments, handles refunds for issues, and distributes earnings to restaurants and drivers with proper fee splits

Non-Functional

• Scalability -- support 100,000+ concurrent orders across multiple cities with peak loads 3x normal during lunch and dinner rushes
• Reliability -- maintain 99.9% uptime for order submission; gracefully degrade features like live tracking rather than fail entirely
• Latency -- driver assignment within 10 seconds, menu browsing under 200ms, location updates every 5-10 seconds with sub-second propagation
• Consistency -- eventual consistency acceptable for driver locations and ETAs; strong consistency required for order state transitions and payment captures

What Interviewers Focus On

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

1. Geospatial Matching and Driver Assignment

The core challenge is efficiently pairing ready orders with nearby available drivers while respecting capacity constraints and optimizing for delivery time. Poor matching logic causes cold food, long wait times, and driver inefficiency.

Hints to consider:

• Partition the city into geographic cells (S2, H3, or geohash) to limit search radius and distribute load across shards
• Maintain driver availability in a fast in-memory store with geospatial indexing for sub-second proximity queries
• Use optimistic locking or short-lived reservations to prevent multiple orders from claiming the same driver during high contention
• Consider how batching multiple pickups affects matching complexity and whether you assign greedily or use optimization algorithms

2. Order State Machine and Failure Handling

Orders progress through multiple states (placed, confirmed, preparing, ready, picked up, delivered) with transitions triggered by different actors. State management must be idempotent and handle timeouts, cancellations, and no-shows without corrupting the workflow.

Hints to consider:

• Model the order lifecycle as an explicit state machine with valid transitions and compensating actions for each failure mode
• Handle restaurant rejections (out of ingredients, too busy) by automatically reassigning to alternate restaurants or refunding customers
• Define timeout policies for each state and implement automatic escalations when restaurants don't respond or drivers don't arrive
• Ensure idempotency for all state transitions since mobile apps may retry requests and multiple services react to the same events

3. Real-Time Location Streaming and ETA Calculation

Drivers continuously stream GPS coordinates while customers demand smooth map updates and accurate time estimates. This creates a high-throughput ingest problem coupled with complex ETA modeling based on traffic and restaurant preparation time.

Hints to consider:

• Use a message queue to decouple location ingest from fan-out; drivers publish to a topic partitioned by driver ID or geo-cell
• Apply intelligent throttling and delta compression to reduce bandwidth while maintaining visual smoothness on customer apps
• Compute ETAs by combining multiple signals: historical data, current traffic APIs, restaurant prep time averages, and driver route progress
• Consider fallback strategies when WebSocket connections drop, such as long polling or exponential backoff for reconnection

4. Menu Inventory and Dynamic Pricing

Restaurants update menus, mark items unavailable, and adjust prices throughout the day. The system must reflect these changes quickly while handling race conditions when customers order an item that just sold out, and support surge pricing during peak demand.

Hints to consider:

• Cache menu data with short TTLs at the edge, but validate critical fields like price and availability at order submission time
• Use an inventory service that tracks item availability and handles optimistic concurrency when multiple customers order the last item
• Implement dynamic pricing as a separate service that adjusts delivery fees based on driver supply, demand surge, and distance
• Design the checkout flow to gracefully handle price changes or item unavailability between browsing and payment confirmation

5. Payment Flow and Financial Reconciliation

The platform must capture funds from customers, hold them during delivery, handle refunds for problems, and accurately split payouts among restaurants, drivers, and the platform while maintaining an audit trail for disputes.

Hints to consider:

• Use payment holds (authorize but don't capture immediately) to handle cancellations before pickup without double-charging customers
• Implement a ledger service that records all financial transactions as immutable events for accurate reconciliation and dispute resolution
• Design compensating transactions for partial refunds when orders are incomplete or quality issues arise after delivery
• Ensure idempotency keys for all payment gateway calls to prevent duplicate charges during retries or network failures

Suggested Approach

Step 1: Clarify Requirements

Start by confirming scope and constraints with the interviewer. Ask about target scale (orders per hour, number of cities), whether the system should support restaurant chains with multiple locations, if driver batching (delivering multiple orders in one trip) is required, and what SLAs matter most. Clarify whether you need to design the restaurant kitchen integration or treat it as a black box. Confirm if surge pricing, scheduled orders, and group orders are in scope. Establish the consistency model for inventory and whether partial failures should cancel orders or allow partial fulfillment.

Step 2: High-Level Architecture

Sketch the major services: API Gateway for mobile apps, Order Service managing the state machine, Restaurant Service handling menus and fulfillment, Driver Service tracking availability and location, Dispatch Service for matching logic, Tracking Service for real-time updates, Payment Service coordinating financial flows, and Notification Service for push alerts. Identify key data stores: relational database for orders and users, document store for restaurant menus, geospatial cache (Redis with geo commands) for driver locations, message queue (Kafka) for location streams and order events, and time-series database for analytics. Show how mobile apps connect via WebSocket for live updates and REST for transactional operations.

Step 3: Deep Dive on Dispatch and Matching

Walk through the driver assignment algorithm in detail since it's the most critical and complex piece. When a restaurant marks an order ready for pickup, the Dispatch Service queries the geospatial cache for drivers within a radius (e.g., 2 miles), filters by availability and vehicle type, ranks by distance and acceptance rate, then attempts to reserve the top candidate using a distributed lock with TTL. If the driver accepts within 30 seconds, transition the order to "assigned"; if they decline or timeout, release the lock and try the next candidate. Discuss sharding the cache by geo-cell to avoid hotspots, handling edge cases like no available drivers (widen radius, increase incentives), and batching logic that groups nearby orders to the same driver. Explain how you'd prevent double-assignment races using Redis SETNX or conditional updates in your database.

Step 4: Address Secondary Concerns

Cover remaining non-functional requirements efficiently. For scalability, explain horizontal partitioning strategies (orders by city and time range, menus by restaurant ID) and read replica patterns for menu browsing. For reliability, discuss circuit breakers around payment gateways, graceful degradation when tracking is unavailable, and retry policies with exponential backoff. Address monitoring by tracking key metrics like assignment latency, order cancellation rate, ETA accuracy, and payment success rate. Touch on security concerns like authenticating driver location updates, validating menu prices at checkout, and PCI compliance for payment data. Mention how you'd use feature flags to roll out new dispatch algorithms and A/B test pricing strategies. Finally, briefly outline the data pipeline for analytics, fraud detection, and machine learning models that improve ETA prediction and restaurant prep time estimates.

Related Learning

Deepen your understanding of the patterns used in this problem:

• Uber -- end-to-end ride-sharing architecture with geospatial matching and real-time tracking
• Google Maps -- geospatial indexing, routing algorithms, and map tile serving at scale
• Payment System -- idempotent payment capture, refund workflows, and ledger reconciliation
• Message Queues -- event-driven location streaming and order state change propagation via Kafka
• Databases -- partitioning strategies for orders and geospatial indexing with Redis GeoHash
• Caching -- hot cache layers for driver locations, menus, and ETA estimates
• Load Balancers -- distributing API traffic across regional service clusters