Food Delivery System Design (HLD & LLD)

Functional Requirements

Customer

• Search restaurants
• Browse menu
• Add items to cart
• Place order
• Online payment / Cash on Delivery (COD)
• Track order
• View order history

Restaurant

• Manage menu
• Accept or reject orders
• Update order status

Delivery Partner

• Accept delivery requests
• Pick up orders
• Deliver orders
• Update delivery status

Non-Functional Requirements

• High availability
• Low latency
• Horizontal scalability
• Fault tolerance
• Real-time tracking
• High throughput during peak hours

High-Level Architecture

flowchart TD
    A["Client Apps<br/>Customer / Restaurant / Delivery Partner"]
    A --> B[API Gateway]

    B --> U[User Service]
    B --> R[Restaurant Service]
    B --> O[Order Service]
    B --> P[Payment Service]
    B --> D[Delivery Service]
    B --> N[Notification Service]

    O --> K[(Kafka / Message Queue)]
    K --> W[Tracking / Analytics / Notification Workers]

Components

API Gateway

• Authentication
• Rate limiting
• Routing
• Logging

User Service

• User profile
• Addresses
• Authentication

Restaurant Service

• Restaurant data
• Menu management
• Availability

Order Service

• Cart
• Order creation
• Order state management

Payment Service

• Payment gateway integration
• Refunds
• Transaction tracking

Delivery Service

• Assign delivery partner
• Track delivery status

Notification Service

• Push notifications
• SMS
• Email

Message Queue

• Order events
• Delivery updates
• Notifications

Order Flow

1. User selects restaurant and menu items.
2. Client invokes the Create Order API.
3. Order Service validates items, creates the order, and publishes an event.
4. Payment Service processes payment.
5. Restaurant accepts the order.
6. Delivery partner is assigned.
7. Order status is updated throughout the lifecycle.
8. Notifications are sent to the customer.

sequenceDiagram
    participant C as Customer
    participant O as Order Service
    participant P as Payment Service
    participant R as Restaurant
    participant D as Delivery Service

    C->>O: Create Order
    O->>P: Process Payment
    P-->>O: Success
    O->>R: Send Order
    R-->>O: Accept Order
    O->>D: Assign Driver
    D-->>C: Live Status Updates

Database Design

Users

Users
-----
user_id (PK)
name
phone
email
created_at

Restaurants

Restaurants
-----------
restaurant_id (PK)
name
location
rating
is_open

Menu Items

MenuItems
---------
item_id (PK)
restaurant_id (FK)
name
price
is_available

Orders

Orders
------
order_id (PK)
user_id
restaurant_id
status
total_price
payment_status
created_at

Order Items

OrderItems
----------
id
order_id
item_id
quantity
price

Delivery

Delivery
--------
delivery_id
order_id
driver_id
status
pickup_time
delivery_time

ER Diagram

erDiagram
    USERS ||--o{ ORDERS : places
    RESTAURANTS ||--o{ MENU_ITEMS : offers
    RESTAURANTS ||--o{ ORDERS : receives
    ORDERS ||--|{ ORDER_ITEMS : contains
    MENU_ITEMS ||--o{ ORDER_ITEMS : references
    ORDERS ||--|| DELIVERY : fulfilled_by

Order State Machine

stateDiagram-v2
    [*] --> CREATED
    CREATED --> PAYMENT_PENDING
    PAYMENT_PENDING --> PAYMENT_SUCCESS
    PAYMENT_PENDING --> PAYMENT_FAILED
    PAYMENT_SUCCESS --> RESTAURANT_ACCEPTED
    RESTAURANT_ACCEPTED --> PREPARING
    PREPARING --> PICKED_UP
    PICKED_UP --> DELIVERED
    CREATED --> CANCELLED
    RESTAURANT_ACCEPTED --> REJECTED_BY_RESTAURANT

Delivery Partner Assignment

Use:

• GeoHash
• Redis GeoSpatial Index

Algorithm:

Find drivers within a 3 km radius
Sort by distance
Assign the first available driver

For the full geospatial matching mechanics (Redis GEOADD/GEORADIUS, handling hundreds of thousands of location updates/sec, and preventing double-assignment race conditions), see the Ride Booking system design case study.

Real-Time Order Tracking

flowchart LR
    A[Driver App] --> B[Location Service]
    B --> C[WebSocket / SSE]
    C --> D[Customer App]

Technologies:

• WebSocket
• Redis Pub/Sub
• Kafka Streaming

Caching Strategy

Use Redis for:

• Restaurant list
• Menu items
• Active drivers
• Frequently ordered items

Example key:

menu:{restaurant_id}

Scaling Strategy

Read Scaling

• Read replicas
• CDN for images
• Redis cache

Write Scaling

• Shard orders table
• Partition by order ID or region

Microservices

• Kubernetes deployment
• Autoscaling

Handling Peak Traffic

• Queue incoming orders
• Rate limiting
• Load balancing
• Autoscaling

Failure Handling

Use the Saga Pattern.

Workflow:

Create Order
-> Process Payment
-> Confirm Restaurant
-> Assign Delivery

Compensation:

Refund Payment

Security

• JWT authentication
• HTTPS
• Rate limiting
• Fraud detection
• Secure payment gateway integration

Low-Level Design (LLD)

Order

class Order {
    String orderId;
    Long userId;
    Long restaurantId;
    List<OrderItem> items;
    OrderStatus status;
    PaymentStatus paymentStatus;
    BigDecimal totalPrice;
}

OrderItem

class OrderItem {
    Long itemId;
    int quantity;
    BigDecimal price;
}

Delivery

class Delivery {
    String deliveryId;
    Long driverId;
    String orderId;
    DeliveryStatus status;
    Location currentLocation;
}

APIs

Create Order

POST /orders

Request:

{
  "restaurantId": 101,
  "items": [
    {
      "itemId": 1,
      "qty": 2
    },
    {
      "itemId": 5,
      "qty": 1
    }
  ]
}

Track Order

GET /orders/{orderId}/status

Restaurant Menu

GET /restaurants/{id}/menu

Advanced Interview Topics

• Multi-region deployment
• ETA prediction using machine learning
• Dynamic pricing
• Surge delivery fee
• Restaurant ranking algorithm
• Fraud detection
• Delivery batching

Key Takeaways

• Microservices isolate business capabilities and scale independently.
• Event-driven communication improves resilience and decouples services.
• Redis and Kafka are critical for low latency and asynchronous workflows.
• Geo-spatial indexing enables efficient driver matching.
• Saga pattern provides reliable distributed transaction handling.