High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

Codemia

Problem

Editorial

Design a Food Delivery Service

System requirements

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.

Non-Functional

Low latency: Restaurant search and menu loading under 200ms. Order placement confirmation within 1 second. Driver location updates delivered to the user's map within 2 seconds of the driver's GPS reading.
High availability: 99.9% uptime. An active order must never be lost, if a service crashes mid-order, the order resumes from its last known state on recovery. Payment and order data are the most critical; recommendation and analytics services can degrade.
Scalability: Handle 10M daily orders, with 70% concentrated in 4 peak hours (11 AM–1 PM, 6–8 PM). Peak concurrent orders: ~500K. Scale horizontally for all stateless services. The system must handle "Super Bowl Sunday" traffic surges (3-5x normal peak) without degradation.

Capacity estimation

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 data: 10M orders/day × 2KB per order (items, addresses, status history) = 20GB/day = 7.3TB/year. Partitioned by date for archival.
Driver locations: Only current location matters (overwrites every 5 seconds). 200K drivers × 100 bytes = 20MB in Redis. Historical location traces for dispute resolution: 40K writes/sec × 100 bytes × 86,400 sec = ~350GB/day → stored in time-series DB or Parquet for cold archival.
Restaurant/menu data: 500K restaurants × 50 menu items × 500 bytes = 12.5GB. Small enough for aggressive caching in Redis.
Images: 500K restaurants × 50 items × 200KB avg photo = 5TB. Served via CDN, not from origin.

Bandwidth

API bandwidth: 10K req/sec × 5KB avg response = 50 MB/sec = 400 Mbps. Modest.
Location tracking: 40K writes/sec × 100 bytes = 4 MB/sec inbound. 500K WebSocket pushes/sec × 100 bytes = 50 MB/sec outbound = 400 Mbps for tracking alone.
Image bandwidth: CDN handles this. Origin bandwidth is negligible due to high cache hit rates on food photos.

API design

Order APIs

POST /v1/orders

json

{
  "restaurantId": "rest_abc",
  "items": [
    {"menuItemId": "item_1", "quantity": 2, "customizations": ["extra cheese"]},
    {"menuItemId": "item_2", "quantity": 1, "customizations": []}
  ],
  "deliveryAddress": {"lat": 37.7749, "lng": -122.4194, "formatted": "123 Main St"},
  "paymentMethodId": "pm_xyz",
  "idempotencyKey": "ord_client_abc123",
  "scheduledFor": null,
  "tip": 500
}

Returns 201 with order ID, estimated delivery time, and order total. The idempotencyKey is client-generated, if the client retries (network timeout), the server detects the duplicate key and returns the existing order instead of creating a new one.

GET /v1/orders/{orderId}. Full order details including items, status, driver info, and status history.

POST /v1/orders/{orderId}/cancel. Cancel with a required reason field. Only allowed in states: placed, confirmed. Returns 409 if the order is already being prepared.

Restaurant APIs

GET /v1/restaurants?lat={lat}&lng={lng}&radius=5km&cuisine=italian&sort=rating

Returns paginated list of nearby open restaurants with name, cuisine, rating, estimated delivery time, and delivery fee. Results filtered by operating hours (don't show closed restaurants) and the user's delivery radius.

GET /v1/restaurants/{restaurantId}/menu. Full menu grouped by category (appetizers, mains, drinks) with item names, descriptions, photos, prices, and availability flags.

PUT /v1/restaurants/{restaurantId}/menu/{itemId}. Update item details or mark as sold out. Setting available: false immediately hides the item from users browsing the menu.

Driver APIs

POST /v1/driver/location

json

{"lat": 37.7750, "lng": -122.4195, "heading": 90, "speed": 25, "timestamp": "2026-03-01T18:30:00Z"}

Called every 5 seconds by the driver app. Writes to Redis with geohash index. Minimal payload for bandwidth efficiency on cellular connections.

POST /v1/orders/{orderId}/accept. Driver accepts a delivery offer. Uses optimistic locking (the offer includes a version token), if another driver already accepted (shouldn't happen with sequential offers), returns 409.

POST /v1/orders/{orderId}/status. Driver updates order status: picked_up, arrived, delivered. Each transition is validated against the state machine.

GET /v1/driver/earnings?from=2026-02-01&to=2026-02-28. Returns the driver's earnings breakdown: total earnings, number of deliveries, tips, and bonuses for the specified period. Used by the driver app's earnings dashboard.

Tracking API

WebSocket /v1/tracking/{orderId}. Client connects after order placement. Server pushes: status changes (preparing → ready → picked up → delivered), driver location updates (every 5 seconds when en route), and ETA updates. The connection is authenticated via a short-lived token in the handshake.

Database design

Schema

Table	Key Columns	Notes
users	user_id (PK), email (UNIQUE), name, phone, default_address (JSONB)	Customer accounts
restaurants	restaurant_id (PK), name, location (POINT), cuisine_type, rating, operating_hours (JSONB), is_active	PostGIS for geo queries
menu_items	item_id (PK), restaurant_id (FK), name, price_cents, category, is_available, customizations (JSONB)	Per-restaurant menus
orders	order_id (PK), user_id (FK), restaurant_id (FK), driver_id (FK), status, items (JSONB), total_cents, delivery_address (JSONB), idempotency_key (UNIQUE)	Items stored as point-in-time snapshot; idempotency_key prevents duplicate orders
order_status_history	id (PK), order_id (FK), status, changed_by, changed_at	Audit trail, who changed status and when
drivers	driver_id (PK), name, phone, vehicle_type, is_available, rating	Current location stored in Redis, not here
payments	payment_id (PK), order_id (FK), amount_cents, method, status, provider_txn_id	Status: authorized → captured → refunded

Storage Engine Choices

PostgreSQL for orders, users, restaurants, menu items, payments, relational data with ACID requirements. Order placement is a transaction across orders, order_status_history, and payments tables. PostGIS extension enables geospatial queries: SELECT * FROM restaurants WHERE ST_DWithin(location, ST_MakePoint(lng, lat), 5000) finds restaurants within 5km. Read replicas handle the 10K req/sec read traffic during peak hours.

Redis for real-time driver locations, each driver's current position stored as a Redis geospatial entry: GEOADD drivers:locations lng lat driver_id. Finding nearest drivers: GEORADIUS drivers:locations lng lat 5 km COUNT 10 ASC. Sub-millisecond reads. Also stores: idempotency keys (SET with TTL), rate limiting counters, and cached restaurant menus (cache-aside pattern: on menu request, check Redis first; on cache miss, read from PostgreSQL, populate Redis with a 5-minute TTL, and return. When a restaurant updates their menu, invalidate the cache key so the next request fetches fresh data).

Kafka for event streaming, order state transitions, driver location traces, payment events, and notification triggers all flow through Kafka topics. Decouples producers from consumers. Enables replay for recovery.

S3 + CDN for images, restaurant photos, food item images. Immutable once uploaded. CDN cache hit rate ~99% for food photos (they rarely change).

Key Indexes

orders(user_id, created_at DESC), user's order history
orders(restaurant_id, status), restaurant's pending orders
orders(driver_id, status), driver's active deliveries
orders(idempotency_key), unique index for duplicate prevention
restaurants(location). GiST index for geospatial proximity search
menu_items(restaurant_id, is_available), available items per restaurant

High-level design

Food delivery platform: clients, API gateway, microservices, and data stores

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10