Design a Food Delivery Service

Functional

A food delivery service connects hungry users, restaurants, and delivery drivers through a real-time marketplace. Think DoorDash, Uber Eats, or Grubhub. The platform coordinates three distinct user types with very different needs: customers ordering food, restaurants preparing it, and drivers delivering it.

• Order placement: Users browse nearby restaurants, view menus with photos and prices, add items to a cart with customization options (extra sauce, no onions, spice level), and checkout. The system validates item availability against the restaurant's current menu before processing payment. Support for scheduled orders (order now, deliver at 7 PM).
• Real-time order tracking: After placing an order, the user sees live status updates: confirmed → preparing → ready for pickup → driver en route → delivered. A map shows the driver's live GPS position updating every few seconds. Estimated delivery time updates dynamically based on driver location and traffic.
• Restaurant management: Restaurants register on the platform, configure operating hours, manage their menu (add/remove/update items, mark items as sold out), and receive incoming orders. The restaurant dashboard shows pending orders with a countdown timer and an "accept/reject" button. Menu changes propagate to users immediately.
• Driver matching and dispatch: When an order is ready for pickup, the system matches it with the nearest available driver. Drivers see available delivery offers with pickup location, drop-off location, estimated pay, and distance. A driver accepts or declines within 30 seconds; on timeout, the offer goes to the next nearest driver.
• Payment processing: Supports credit/debit cards, digital wallets, and cash on delivery. Payment is authorized (hold) at order placement and captured after delivery confirmation. Refunds for cancelled orders or quality issues. Tips added post-delivery.
• Ratings and reviews: Users rate restaurants (1-5 stars) and drivers (thumbs up/down) after delivery. Restaurants rate drivers. These ratings affect search ranking and driver priority in future matching.

Traffic

• Daily orders: 10M orders/day. 70% during 4 peak hours = 7M orders in 14,400 seconds = ~486 orders/sec at peak. Super Bowl spike at 5x = ~2,400 orders/sec.
• API throughput: Each order generates ~15 API calls (browse restaurants, view menu, add to cart, checkout, payment, tracking updates, driver matching, status updates, rating). 10M orders × 15 = 150M API calls/day. Peak: ~10K API requests/sec.
• Driver location updates: 200K active drivers × 1 GPS update every 5 seconds = 40K location writes/sec. Each update is small (driver_id, lat, lng, timestamp) ≈ 100 bytes. This is the highest write throughput in the system.
• WebSocket connections: 500K concurrent orders × 1 user tracking each = 500K concurrent WebSocket connections for live tracking.

Storage

Order APIs

POST /v1/orders

1{
2  "restaurantId": "rest_abc",
3  "items": [
4    {"menuItemId": "item_1", "quantity": 2, "customizations": ["extra cheese"]},
5    {"menuItemId": "item_2", "quantity": 1, "customizations": []}
6  ],
7  "deliveryAddress": {"lat": 37.7749, "lng": -122.4194, "formatted": "123 Main St"},
8  "paymentMethodId": "pm_xyz",
9  "idempotencyKey": "ord_client_abc123",
10  "scheduledFor": null,
11  "tip": 500
12}

Schema

Storage Engine Choices

Components

Client apps (user, restaurant, driver): Three distinct apps. The user app handles browsing, ordering, and tracking. The restaurant app (tablet-based) shows incoming orders with accept/reject buttons and a prep timer. The driver app shows delivery offers, navigation, and a "mark as delivered" button. All three connect through the same API Gateway but access different endpoints.

Order Placement Flow

1. User taps "Place Order" in the app. Client sends POST /v1/orders with cart items, delivery address, payment method, and idempotency key.
2. API Gateway validates JWT, rate-checks, and routes to Order Service.
3. Order Service checks idempotency key in Redis. If exists, returns the existing order (duplicate request). If new, proceeds.
4. Order Service validates: restaurant is open, all items are available (query menu_items), delivery address is within the restaurant's delivery radius. Returns 400 with specific error if any validation fails.
5. Order Service calls Payment Service: authorize (hold) the order total on the user's card. Payment Service calls Stripe, receives authorization. Returns payment_id.
6. Order Service writes to PostgreSQL in a transaction: INSERT into orders (status = "placed"), INSERT into order_status_history, INSERT into payments (status = "authorized"). SET idempotency key in Redis with 24-hour TTL.
7. Order Service publishes order_placed event to Kafka.
8. Returns 201 to the user with order_id, estimated delivery time, and total. The user does not wait for restaurant acceptance, everything below happens asynchronously.
9. Restaurant Service consumes the Kafka event, pushes the order to the restaurant app via push notification and WebSocket.
10. Restaurant accepts the order → publishes order_confirmed event. Order Service updates status to "confirmed." If the restaurant rejects or doesn't respond within 5 minutes, the order is auto-cancelled and the payment hold is released.

Order State Machine: The Core Challenge

This is the heart of the food delivery system. Every order moves through a finite set of states with strictly enforced transitions. Invalid transitions are rejected, preventing corrupted order states.

SQL vs NoSQL for Different Workloads

PostgreSQL for transactional data (orders, payments): ACID compliance is non-negotiable for financial transactions. An order placement involves coordinated writes across orders, order_status_history, and payments, a single transaction guarantees all-or-nothing. PostGIS provides native geospatial queries for restaurant search. The downside: PostgreSQL's write throughput is limited (~10-50K writes/sec per primary, depending on hardware). For 486 orders/sec at peak, this is fine. For 40K location writes/sec; it would be a bottleneck.

Redis for real-time location data: In-memory storage handles 40K writes/sec easily (Redis benchmarks at 100K+ ops/sec). Geospatial commands (GEORADIUS) are purpose-built for the driver matching use case. Trade-off: Redis is volatile, if it crashes, all current driver locations are lost. Mitigation: drivers re-report within 5 seconds, so the data self-heals in seconds. Redis persistence (RDB snapshots) adds a safety net but isn't critical for location data.

Payment Service Failure During Order Placement

User places an order. Order Service calls Payment Service to authorize the card. Payment Service calls Stripe but gets a timeout. What happens?

1. Retry with idempotency key: Payment Service retries the Stripe call with the same idempotency key. Stripe's idempotency ensures the charge is not duplicated even if the first call actually succeeded but the response was lost. Retry up to 3 times with exponential backoff.
2. Circuit breaker: If Payment Service error rate exceeds 50% over the last 100 calls, the circuit opens. Subsequent order placements get a "payment temporarily unavailable" error immediately instead of waiting for timeouts. The user sees "Please try again in a few minutes."
3. Compensation for captured-but-lost orders: Worst case: Stripe successfully authorized, but the Order Service crashed before saving the order. On recovery, a reconciliation job compares Stripe authorizations (via Stripe's list API) with the orders table. Orphaned authorizations are voided. This runs every 15 minutes.

ML-Driven Delivery Time Prediction

Current ETA is distance/speed + restaurant average prep time, a crude estimate. An ML model can incorporate: historical prep times for the specific restaurant and dish type, current restaurant order volume (10 pending orders = longer prep), traffic conditions at this time of day, weather (rain slows delivery 15-20%), and driver historical delivery speed. Training data: millions of past orders with actual timestamps for each state transition. The model predicts each stage independently: prep time, driver pickup time, delivery time. Combined ETA is more accurate than a static formula and adapts to conditions in real time.

Route Optimization for Multi-Order Drivers