Practice/Microsoft/Design Uber

Design Uber

System DesignMust

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

Practice/Microsoft/Design Uber

Design Uber

System DesignMust

Problem Statement

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

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

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

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

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

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