System Design Deep Dive ·

🎯 Design Food Delivery

1️⃣ Core Framework

When discussing Food Delivery design, I frame it as:

Core flows: browse restaurant, place order, deliver order
Restaurant, menu, cart, and order management
Payment and checkout
Order state machine
Dasher / courier dispatch
Real-time tracking and ETA
Inventory, menu availability, and cancellation
Trade-offs: consistency vs latency vs marketplace efficiency

2️⃣ Core Requirements

Functional Requirements

User can browse nearby restaurants
User can view menus
User can add items to cart
User can place an order
Restaurant can accept or reject order
Courier can be assigned for delivery
User can track order status
Support payment, refunds, tips, promotions
Support cancellation
Support ratings and order history

Non-functional Requirements

Low-latency browsing and checkout
High availability
Reliable order state management
Accurate payment handling
Real-time delivery tracking
Scalable restaurant search
Eventual consistency acceptable for tracking and analytics
Stronger consistency needed for payment and order state

👉 Interview Answer

A food delivery system is a marketplace connecting customers, restaurants, and couriers.

The core flows are restaurant discovery, order placement, restaurant preparation, courier dispatch, delivery tracking, and payment.

The main challenge is coordinating many real-time states while keeping order and payment correctness strong.

3️⃣ Main APIs

Search Restaurants

GET /api/restaurants?lat=40.7128&lng=-74.0060&query=sushi

GET /api/restaurants/{restaurantId}/menu

Create Cart

POST /api/cart

Request:

{
  "userId": "u123",
  "restaurantId": "r456",
  "items": [
    {
      "menuItemId": "m1",
      "quantity": 2,
      "options": {
        "spiceLevel": "medium"
      }
    }
  ]
}

Place Order

POST /api/orders

Request:

{
  "userId": "u123",
  "cartId": "c789",
  "deliveryAddressId": "addr1",
  "paymentMethodId": "pm1",
  "tipAmount": 5.00,
  "promoCode": "SAVE10"
}

Update Order State

POST /api/orders/{orderId}/state

Track Delivery

GET /api/orders/{orderId}/tracking

👉 Interview Answer

I would separate APIs for restaurant search, menu retrieval, cart management, order creation, order state updates, and delivery tracking.

Search and menu reads are read-heavy, while order creation and payment require stronger correctness.

4️⃣ Data Model

Restaurant Table

restaurant (
  restaurant_id VARCHAR PRIMARY KEY,
  name VARCHAR,
  location_lat DOUBLE,
  location_lng DOUBLE,
  status VARCHAR,
  rating DOUBLE,
  delivery_radius_km DOUBLE,
  created_at TIMESTAMP
)

menu_item (
  item_id VARCHAR PRIMARY KEY,
  restaurant_id VARCHAR,
  name VARCHAR,
  description TEXT,
  price DECIMAL,
  available BOOLEAN,
  category VARCHAR,
  options JSON,
  updated_at TIMESTAMP
)

Cart Table

cart (
  cart_id VARCHAR PRIMARY KEY,
  user_id VARCHAR,
  restaurant_id VARCHAR,
  status VARCHAR,
  created_at TIMESTAMP,
  updated_at TIMESTAMP
)

Cart Item Table

cart_item (
  cart_id VARCHAR,
  menu_item_id VARCHAR,
  quantity INT,
  selected_options JSON,
  price_snapshot DECIMAL,
  PRIMARY KEY (cart_id, menu_item_id)
)

Order Table

order (
  order_id VARCHAR PRIMARY KEY,
  user_id VARCHAR,
  restaurant_id VARCHAR,
  courier_id VARCHAR,
  state VARCHAR,
  subtotal DECIMAL,
  delivery_fee DECIMAL,
  tax DECIMAL,
  tip DECIMAL,
  discount DECIMAL,
  total DECIMAL,
  payment_status VARCHAR,
  created_at TIMESTAMP,
  updated_at TIMESTAMP
)

Order Event Table

order_event (
  event_id VARCHAR PRIMARY KEY,
  order_id VARCHAR,
  actor_id VARCHAR,
  event_type VARCHAR,
  created_at TIMESTAMP,
  metadata JSON
)

👉 Interview Answer

I would separate restaurants, menus, carts, orders, and order events.

Menu data is read-heavy and can be cached.

Orders are durable transactional records, while order events provide an audit trail for debugging, customer support, and reconciliation.

Restaurant Search Inputs

User location
Restaurant location
Restaurant availability
Delivery radius
Cuisine type
Rating
Estimated delivery time
Promotion
User preference

Search Flow

User opens app
→ Location service gets user location
→ Restaurant service finds nearby restaurants
→ Filter open/available restaurants
→ Rank by ETA, rating, relevance, fees
→ Return list

Menus should be cached because they are read-heavy.

Cache:

Restaurant metadata
Menu items
Item availability
Pricing snapshot
Popular items

👉 Interview Answer

Restaurant discovery is a geo-search problem.

I would find restaurants within the delivery radius, filter by open status and availability, then rank by ETA, rating, relevance, fees, and promotions.

Menu data is read-heavy, so it should be cached aggressively, while availability may need shorter TTLs.

6️⃣ Cart and Checkout

Cart Responsibilities

Store selected items
Store item options
Validate item availability
Calculate subtotal
Apply promotions
Estimate tax, fees, tip, and delivery time

Price Snapshot

When user adds item to cart, store price snapshot.

Why?

Menu price may change
Checkout should be predictable
Order history should preserve original price

Checkout Validation

Before order creation:

Validate restaurant is open
Validate items are available
Validate delivery address
Recalculate final price
Validate promo code
Pre-authorize payment

👉 Interview Answer

Cart is temporary, but checkout must revalidate everything.

Before creating an order, I would check restaurant availability, menu item availability, delivery address, promotion validity, final price, and payment pre-authorization.

This prevents stale cart data from creating invalid orders.

7️⃣ Order State Machine

Common States

CREATED
PAYMENT_AUTHORIZED
SENT_TO_RESTAURANT
RESTAURANT_ACCEPTED
PREPARING
READY_FOR_PICKUP
COURIER_ASSIGNED
PICKED_UP
OUT_FOR_DELIVERY
DELIVERED
CANCELLED
REFUNDED

Why State Machine Matters

Prevent invalid transitions
Coordinate restaurant, courier, user, and payment
Support retries
Support cancellation rules
Provide auditability

Example Transitions

CREATED → PAYMENT_AUTHORIZED
PAYMENT_AUTHORIZED → SENT_TO_RESTAURANT
SENT_TO_RESTAURANT → RESTAURANT_ACCEPTED
RESTAURANT_ACCEPTED → PREPARING
PREPARING → READY_FOR_PICKUP
READY_FOR_PICKUP → PICKED_UP
PICKED_UP → OUT_FOR_DELIVERY
OUT_FOR_DELIVERY → DELIVERED

👉 Interview Answer

I would model the order lifecycle as a state machine.

This prevents invalid transitions, makes retries safer, and coordinates restaurant preparation, courier delivery, notifications, and payment capture.

Payment capture should happen only after the order is accepted or after delivery, depending on business rules.

8️⃣ Payment Flow

Payment Strategy

Use:

Pre-authorize at checkout
Capture after restaurant accepts or delivery completes
Refund on cancellation or failure

Why Pre-authorize?

Validate payment method
Reduce failed orders
Protect restaurant and courier workflow

Payment Flow

User places order
→ Payment service pre-authorizes amount
→ Order sent to restaurant
→ Restaurant accepts
→ Payment captured or held
→ Order delivered
→ Final adjustments/refunds if needed

Correctness

Use:

Idempotency key
Payment state machine
Transaction records
Reconciliation jobs
Provider-safe retries

👉 Interview Answer

Payment requires strong correctness.

I would pre-authorize payment during checkout, then capture after restaurant acceptance or after delivery depending on policy.

All payment operations should be idempotent to prevent duplicate charges or refunds.

9️⃣ Restaurant Order Handling

Restaurant Flow

Order created
→ Send to restaurant tablet/POS
→ Restaurant accepts or rejects
→ Restaurant estimates preparation time
→ Kitchen prepares food
→ Marks ready for pickup

Integration Options

Restaurant tablet app
POS integration
Email / phone fallback
Web dashboard

Failure Cases

Restaurant does not respond
Restaurant rejects order
Item unavailable
Prep time changes
Store closes unexpectedly

👉 Interview Answer

After checkout, the order must be confirmed by the restaurant.

The restaurant can accept, reject, or update preparation time.

If the restaurant does not respond, the system should timeout, cancel the order, notify the user, and release or refund payment authorization.

🔟 Courier Dispatch

Dispatch Inputs

Restaurant location
Customer location
Courier location
Courier availability
Vehicle type
Current courier workload
Estimated pickup time
Delivery ETA
Courier acceptance probability

Dispatch Flow

Restaurant accepts order
→ Estimate preparation time
→ Find nearby couriers
→ Rank couriers
→ Send offer to best courier
→ Courier accepts
→ Assign courier to order

Matching Strategy

Choose courier based on:

ETA to restaurant
ETA from restaurant to customer
Courier availability
Batch delivery opportunity
Acceptance probability
Fairness / utilization

Avoid Double Assignment

Use atomic conditional update:

UPDATE courier
SET status = 'ASSIGNED'
WHERE courier_id = 'd123'
AND status = 'AVAILABLE';

👉 Interview Answer

Courier dispatch is similar to ride matching, but it must also consider restaurant prep time.

The best courier is not always the closest courier. We want the courier to arrive near the time food is ready, minimizing both courier wait time and food delay.

Assignment must be atomic to avoid double assignment.

1️⃣1️⃣ ETA System

ETA Types

Restaurant prep ETA
Courier ETA to restaurant
Pickup ETA
Delivery ETA to customer
Total order ETA

Inputs

Restaurant historical prep time
Current restaurant load
Courier location
Traffic
Distance
Weather
Order size
Time of day

ETA Flow

Estimate prep time
→ Estimate courier arrival time
→ Estimate delivery travel time
→ Combine into total ETA
→ Update ETA as state changes

👉 Interview Answer

Food delivery ETA is more complex than ride-sharing ETA because it includes both food preparation time and delivery time.

I would estimate restaurant prep time, courier travel time to pickup, and courier travel time to customer, then continuously update ETA as the order progresses.

1️⃣2️⃣ Real-time Tracking

Tracking Flow

Courier sends location updates
→ Location service stores latest location
→ Tracking service streams updates to customer
→ Customer app updates map

Tracking Requirements

Show courier location
Show order state
Show updated ETA
Support delayed or missing location updates

Protocol

Use:

WebSocket
Server-sent events
Push notification for major state changes

👉 Interview Answer

For real-time delivery tracking, the courier app sends location updates every few seconds.

The tracking service streams relevant updates to the customer.

Slight delays are acceptable, so location tracking can be eventually consistent.

Availability Challenges

Restaurant may run out of items
Menu may change
Store may close
Item options may become unavailable
Price may change

Strategies

Cache menu with short TTL
Revalidate at checkout
Restaurant can mark items unavailable
Store price snapshot in cart/order
Use event-driven menu updates

👉 Interview Answer

Menu and inventory data can become stale.

I would cache menu data for read performance, but always revalidate item availability and price at checkout.

The final order should store a price snapshot so historical orders remain consistent even if menu prices change later.

1️⃣4️⃣ Promotions and Fees

Promotion Types

Percentage discount
Fixed discount
Free delivery
Restaurant-funded promo
Platform-funded promo
New user promo

Fee Components

Subtotal
Delivery fee
Service fee
Tax
Tip
Discount
Small order fee

Validation

Promo validation checks:

User eligibility
Restaurant eligibility
Minimum order amount
Expiration time
Usage limits
Funding source

👉 Interview Answer

Promotions and fees should be calculated by a dedicated pricing service.

At checkout, the system validates promo eligibility, calculates tax, service fee, delivery fee, discount, tip, and final total.

The calculated price should be stored on the order for auditability.

1️⃣5️⃣ Notifications

Notification Types

Order placed
Restaurant accepted
Restaurant rejected
Courier assigned
Food picked up
Courier nearby
Delivered
Cancelled
Refund issued

Channels

Push notification
SMS fallback
In-app real-time updates
Email receipt

👉 Interview Answer

Notifications are important because food delivery has many state changes.

I would publish order state change events, and a notification service would send push, SMS fallback, in-app updates, or email receipts asynchronously.

1️⃣6️⃣ Scaling Patterns

Pattern 1: Separate Read-heavy and Transactional Paths

Restaurant/menu browsing = read-heavy
Order/payment = transactional

Pattern 2: Geo-sharded Marketplace

Shard by:

city / region / delivery zone

Why?

Food delivery is local
Restaurant and courier matching are region-based
Better latency and fault isolation

Pattern 3: Event-driven Order Pipeline

order state change
→ event bus
→ notification / dispatch / analytics / payment

Cache:

Restaurant list
Menu
Popular items
Ratings
Delivery fee estimates

Pattern 5: Async Analytics

Track:

Order conversion
Delivery time
Prep time
Courier utilization
Cancellation reasons

👉 Interview Answer

To scale food delivery, I would separate read-heavy restaurant browsing from transactional order processing.

Marketplace operations like dispatch should be regionally sharded, because food delivery is naturally local.

Order state changes should publish events to drive notifications, dispatch, payment, and analytics.

1️⃣7️⃣ Failure Handling

Common Failures

Payment pre-auth fails
Restaurant does not respond
Restaurant rejects order
Courier rejects dispatch
Courier app disconnects
Menu data stale
Courier location delayed
Order state update duplicated
Delivery delayed

Strategies

Idempotent order creation
Payment authorization timeout
Restaurant response timeout
Retry dispatch with next courier
Atomic courier assignment
Revalidate menu at checkout
Use order state machine
Refund or credit user when needed
Reconciliation jobs for payment/order mismatch

👉 Interview Answer

The system must be resilient to many partial failures.

Order creation and payment must be idempotent. Restaurant confirmation should have a timeout. Courier dispatch should retry with the next best courier.

All order state transitions should go through a state machine to avoid invalid or duplicated updates.

1️⃣8️⃣ Consistency Model

Stronger Consistency Needed For

Order creation
Payment authorization and capture
Restaurant acceptance
Courier assignment
Cancellation and refund
Final price

Eventual Consistency Acceptable For

Courier location
ETA updates
Menu cache
Restaurant search ranking
Notifications
Analytics
Ratings and reviews

👉 Interview Answer

Food delivery systems require different consistency levels.

Order state, payment, cancellation, refund, and courier assignment require stronger correctness.

But courier location, ETA updates, restaurant ranking, notifications, and analytics can be eventually consistent.

1️⃣9️⃣ Observability

Key Metrics

Restaurant search latency
Menu load latency
Cart conversion rate
Checkout failure rate
Payment failure rate
Restaurant acceptance rate
Courier assignment latency
Courier acceptance rate
Delivery ETA accuracy
Cancellation rate
Refund rate
Order state transition errors

👉 Interview Answer

I would monitor both system health and marketplace health.

Key metrics include checkout failure rate, restaurant acceptance rate, courier assignment latency, courier acceptance rate, ETA accuracy, cancellation rate, and payment failure rate.

These metrics show whether the marketplace is healthy and whether customers are getting reliable delivery.

2️⃣0️⃣ End-to-End Flow

Browse Flow

User opens app
→ Get user location
→ Find nearby restaurants
→ Filter open restaurants
→ Rank by ETA, rating, relevance, promotions
→ Return restaurant list

Order Flow

User builds cart
→ Checkout validates cart
→ Price calculated
→ Payment pre-authorized
→ Order created
→ Restaurant confirms
→ Courier dispatch starts

Delivery Flow

Restaurant prepares food
→ Courier assigned
→ Courier goes to restaurant
→ Courier picks up food
→ Courier delivers to customer
→ Order marked delivered
→ Payment captured
→ Receipt sent

Key Insight

Food Delivery is not just ordering food — it is a local three-sided marketplace coordinating customers, restaurants, and couriers.

🧠 Staff-Level Answer (Final)

👉 Interview Answer (Full Version)

When designing a food delivery system, I think of it as a local three-sided marketplace connecting customers, restaurants, and couriers.

The system has three major flows: restaurant discovery, order placement, and delivery fulfillment.

Restaurant and menu browsing are read-heavy, so I would cache restaurant metadata, menus, popular items, and availability with short TTLs.

Checkout must be more strongly validated. Before creating an order, the system should revalidate restaurant status, item availability, delivery address, promotion eligibility, final price, and payment pre-authorization.

I would model each order as a state machine, with states such as created, payment authorized, sent to restaurant, restaurant accepted, preparing, ready for pickup, courier assigned, picked up, out for delivery, delivered, cancelled, and refunded.

Courier dispatch is geo-based, but unlike ride-sharing, it must also consider restaurant preparation time. The best courier is not always the closest one; we want the courier to arrive near the time food is ready.

Payment requires strong correctness, so I would use pre-authorization, capture, refunds, idempotency keys, and reconciliation jobs.

Real-time tracking and ETA updates can be eventually consistent, because small delays are acceptable.

I would use an event-driven architecture, where order state changes publish events to trigger notifications, dispatch, payment, analytics, and customer updates.

The main trade-offs are order correctness, payment correctness, ETA accuracy, marketplace efficiency, latency, and operational cost.

Ultimately, the goal is to reliably coordinate restaurants, couriers, and customers, while providing fast checkout, accurate ETA, and smooth delivery tracking.

⭐ Final Insight

Food Delivery 的核心不是“下单买食物”，而是一个协调 customer、restaurant 和 courier 的本地三边 marketplace system。

🎯 Design Food Delivery

1️⃣ Core Framework

2️⃣ Core Requirements

Functional Requirements

Non-functional Requirements

3️⃣ Main APIs

Search Restaurants

Get Menu

Create Cart

Place Order

Update Order State

Track Delivery

4️⃣ Data Model

Restaurant Table

Menu Item Table

Cart Table

Cart Item Table

Order Table

Order Event Table

5️⃣ Restaurant Search and Menu Serving

Restaurant Search Inputs

Search Flow

Menu Serving

6️⃣ Cart and Checkout

Cart Responsibilities

Price Snapshot

Checkout Validation

7️⃣ Order State Machine

Common States

Why State Machine Matters

Example Transitions

8️⃣ Payment Flow

Payment Strategy

Why Pre-authorize?

Payment Flow

Correctness

9️⃣ Restaurant Order Handling

Restaurant Flow

Integration Options

Failure Cases

🔟 Courier Dispatch

Dispatch Inputs

Dispatch Flow

Matching Strategy

Avoid Double Assignment

1️⃣1️⃣ ETA System

ETA Types

Inputs

ETA Flow

1️⃣2️⃣ Real-time Tracking

Tracking Flow

Tracking Requirements

Protocol

1️⃣3️⃣ Inventory and Menu Availability

Availability Challenges

Strategies

1️⃣4️⃣ Promotions and Fees

Promotion Types

Fee Components

Validation

1️⃣5️⃣ Notifications

Notification Types

Channels

1️⃣6️⃣ Scaling Patterns

Pattern 1: Separate Read-heavy and Transactional Paths

Pattern 2: Geo-sharded Marketplace

Pattern 3: Event-driven Order Pipeline

Pattern 4: Cache Restaurant and Menu Data

Pattern 5: Async Analytics

1️⃣7️⃣ Failure Handling

Common Failures

Strategies

1️⃣8️⃣ Consistency Model

Stronger Consistency Needed For

Eventual Consistency Acceptable For

1️⃣9️⃣ Observability

Key Metrics

2️⃣0️⃣ End-to-End Flow

Browse Flow

Order Flow