Food Delivery System Design

A system design case study for a food delivery platform covering restaurant discovery, ordering, dispatch, tracking, notifications, and payments.

Food delivery platforms such as Uber Eats, DoorDash, Swiggy, and Zomato process millions of orders every day while coordinating customers, restaurants, delivery partners, payment providers, GPS services, and notifications in real time.

Unlike a traditional e-commerce application, a food delivery platform is a real-time distributed system where timing, location, and logistics are equally important.

In this series, we'll design a production-grade Food Delivery System capable of handling millions of users and thousands of concurrent orders.

Learning Objectives

After completing this article you'll understand:

Food delivery business model
Customer journey
Restaurant workflow
Delivery partner workflow
Business requirements
Functional requirements
Non-functional requirements
Capacity estimation
High-level architecture
Core microservices
Order lifecycle
Delivery lifecycle

What is a Food Delivery System?

A Food Delivery System connects:

Customers
Restaurants
Delivery Partners
Payment Providers
Location Services

The platform enables customers to:

Discover nearby restaurants
Browse menus
Place orders
Make payments
Track deliveries
Rate restaurants

Business Model

Food delivery platforms generate revenue from multiple sources.

Revenue Source	Description
Delivery Fee	Charged to customers
Restaurant Commission	Percentage of each order
Platform Fee	Service fee
Surge Pricing	Peak-hour delivery charges
Advertisements	Sponsored restaurants
Membership Plans	Premium subscriptions

Primary Actors

The platform consists of multiple actors.

flowchart LR

Customer

Restaurant

Driver

Admin

Customer --> Platform

Restaurant --> Platform

Driver --> Platform

Admin --> Platform

Customer Journey

A customer typically follows these steps:

Login
Detect location
Search restaurants
Browse menu
Add food to cart
Apply coupon
Make payment
Track order
Receive delivery
Rate restaurant

Restaurant Journey

Restaurant operations include:

Receive order
Accept or reject
Prepare food
Mark ready
Hand over to driver

Delivery Partner Journey

Driver workflow:

Go online
Receive delivery request
Accept order
Pick up food
Navigate
Deliver order
Complete delivery

Functional Requirements

The platform should support:

Customer registration
Restaurant onboarding
Menu management
Restaurant search
Cart management
Order placement
Coupon engine
Secure payments
Delivery assignment
GPS tracking
Notifications
Ratings & reviews
Order history
Refunds

Non-Functional Requirements

The platform must provide:

High availability
Low latency
Horizontal scalability
Fault tolerance
High throughput
Security
Reliability
Observability
Disaster recovery

Capacity Estimation

Example assumptions

Daily Active Users

25 Million

Daily Orders

12 Million

Peak Concurrent Users

2 Million

Peak Orders Per Second

8,000

Storage Estimation

Average order data

5 KB

Daily Storage

12 Million × 5 KB

≈ 60 GB/day

Annual Storage

≈ 22 TB/year

Food images and receipts should be stored separately in object storage.

Core Business Concepts

Restaurant

A restaurant manages:

Menus
Inventory
Pricing
Availability
Preparation time

Each menu contains:

Categories
Food items
Variants
Add-ons
Prices

Cart

The shopping cart stores:

Food items
Quantity
Taxes
Delivery charges
Discounts

Order

Each order contains:

Customer
Restaurant
Driver
Payment
Status
Delivery address

Delivery

Delivery consists of:

Driver assignment
Pickup
GPS navigation
Customer delivery
Completion

Payment

Supported methods:

Credit Card
Debit Card
Digital Wallet
Apple Pay
Google Pay
PayPal
Gift Card

Ratings & Reviews

Customers can rate:

Restaurant
Food quality
Delivery experience
Delivery partner

Order Lifecycle

flowchart LR

Cart

Cart --> Checkout

Checkout --> Payment

Payment --> Restaurant

Restaurant --> Preparing

Preparing --> Ready

Ready --> Pickup

Pickup --> Delivery

Delivery --> Completed

Delivery Lifecycle

flowchart LR

Online

Online --> Assigned

Assigned --> Pickup

Pickup --> Traveling

Traveling --> Delivered

Delivered --> Offline

High-Level Architecture

flowchart TD

Customer

Restaurant

Driver

Customer --> Gateway

Restaurant --> Gateway

Driver --> Gateway

Gateway --> CustomerService

Gateway --> RestaurantService

Gateway --> SearchService

Gateway --> CartService

Gateway --> OrderService

Gateway --> PaymentService

Gateway --> DeliveryService

Gateway --> NotificationService

Enterprise Architecture

flowchart TD

Customer

Restaurant

Driver

Customer --> API

Restaurant --> API

Driver --> API

API --> Authentication

API --> Customer

API --> Restaurant

API --> Menu

API --> Search

API --> Cart

API --> Order

API --> Payment

API --> Driver

API --> Delivery

API --> Notification

API --> Review

Core Microservices

Service	Responsibility
API Gateway	Request routing
Authentication Service	Login & JWT
Customer Service	Customer profiles
Restaurant Service	Restaurant management
Menu Service	Food catalog
Search Service	Restaurant discovery
Cart Service	Shopping cart
Order Service	Order management
Payment Service	Payment processing
Driver Service	Driver management
Delivery Service	Delivery tracking
Notification Service	Push, SMS, Email
Review Service	Ratings & reviews
Promotion Service	Coupons & offers
Analytics Service	Business reporting

Service Responsibilities

Customer Service

Responsible for:

Customer profile
Saved addresses
Favorite restaurants
Order history

Restaurant Service

Responsible for:

Restaurant profile
Business hours
Availability
Ratings

Menu Service

Responsible for:

Categories
Food items
Prices
Add-ons
Availability

Search Service

Responsible for:

Nearby restaurants
Cuisine filters
Ratings
Delivery time
Recommendations

Cart Service

Responsible for:

Cart items
Quantity
Discounts
Delivery fee calculation

Order Service

Responsible for:

Order creation
Status updates
Restaurant communication
Delivery coordination

Driver Service

Responsible for:

Driver profile
Current location
Availability
Earnings

Delivery Service

Responsible for:

Driver assignment
GPS tracking
ETA
Route updates

Payment Service

Responsible for:

Payment authorization
Payment capture
Refunds
Wallet support

Order Flow

flowchart LR

Customer

Customer --> Search

Search --> Restaurant

Restaurant --> Cart

Cart --> Payment

Payment --> Restaurant

Restaurant --> Driver

Driver --> Customer

Restaurant Workflow

flowchart LR

Order

Order --> Accept

Accept --> Cook

Cook --> Ready

Ready --> Pickup

Driver Workflow

flowchart LR

Available

Available --> Assigned

Assigned --> Pickup

Pickup --> Delivery

Delivery --> Completed

Notification Flow

Customers receive notifications for:

Order accepted
Food preparing
Driver assigned
Driver arrived
Order delivered

Security Requirements

The platform should support:

OAuth2
JWT
TLS 1.3
Encryption
Rate limiting
MFA for administrators
Secure payment processing
API validation

Compliance

Depending on geography, the platform may need to comply with:

PCI DSS
GDPR
CCPA
SOC 2
Local food delivery regulations

High Availability Goals

Target Availability

99.99%

Recovery Objectives

Metric	Target
RPO	Near Zero
RTO	Less than 30 Minutes

Design Principles

Microservices architecture
Event-Driven communication
API-first design
Database per service
Cloud-native deployment
Horizontal scaling
Immutable order history
Fault isolation
High observability
Security by design

Low-Level Architecture, Database Design, REST APIs & Event-Driven Architecture

In Part 1, we explored the business requirements, high-level architecture, customer journey, restaurant workflow, and core microservices.

In this part, we'll design the internal implementation of an enterprise-scale Food Delivery System similar to Uber Eats, DoorDash, Swiggy, or Zomato.

Topics covered:

Low-Level Architecture
Database Design
Entity Relationship Diagram
Customer Management
Restaurant Management
Menu Management
Inventory Management
Cart Management
Order Management
Payment Management
Driver Management
Delivery Management
Review System
Promotion Engine
REST APIs
Sequence Diagrams
Event-Driven Architecture
Kafka Topics

Low-Level Architecture

Each business capability is implemented as an independent microservice.

flowchart LR

Gateway

Gateway --> Customer

Gateway --> Restaurant

Gateway --> Menu

Gateway --> Search

Gateway --> Cart

Gateway --> Order

Gateway --> Payment

Gateway --> Driver

Gateway --> Delivery

Gateway --> Review

Gateway --> Promotion

Gateway --> Notification

Database Per Service

Each microservice owns its own database.

Benefits:

Independent deployment
Independent scaling
Loose coupling
Fault isolation
Polyglot persistence
Easier maintenance

Database Architecture

flowchart TD

CustomerService --> CustomerDB

RestaurantService --> RestaurantDB

MenuService --> MenuDB

CartService --> CartDB

OrderService --> OrderDB

PaymentService --> PaymentDB

DriverService --> DriverDB

DeliveryService --> DeliveryDB

ReviewService --> ReviewDB

PromotionService --> PromotionDB

Customer Database

Customer Table

Column	Type
customer_id	UUID
first_name	VARCHAR
last_name	VARCHAR
email	VARCHAR
phone	VARCHAR
status	VARCHAR
created_at	TIMESTAMP

Customer Address

Column	Type
address_id	UUID
customer_id	UUID
address_line	VARCHAR
city	VARCHAR
state	VARCHAR
zip_code	VARCHAR
latitude	DECIMAL
longitude	DECIMAL

Multiple delivery addresses are supported.

Restaurant Database

Restaurant Table

Column	Type
restaurant_id	UUID
restaurant_name	VARCHAR
cuisine	VARCHAR
rating	DECIMAL
latitude	DECIMAL
longitude	DECIMAL
status	VARCHAR

Restaurant Schedule

Column	Type
schedule_id	UUID
restaurant_id	UUID
opening_time	TIME
closing_time	TIME
delivery_radius	INTEGER

Column	Type
category_id	UUID
restaurant_id	UUID
category_name	VARCHAR

Column	Type
item_id	UUID
category_id	UUID
item_name	VARCHAR
description	TEXT
price	DECIMAL
preparation_time	INTEGER
available	BOOLEAN

Column	Type
addon_id	UUID
item_id	UUID
addon_name	VARCHAR
addon_price	DECIMAL

Inventory Database

Inventory prevents customers from ordering unavailable food.

Inventory Table

Column	Type
inventory_id	UUID
restaurant_id	UUID
item_id	UUID
quantity	INTEGER
status	VARCHAR
updated_at	TIMESTAMP

Cart Database

Cart

Column	Type
cart_id	UUID
customer_id	UUID
restaurant_id	UUID
total_amount	DECIMAL
updated_at	TIMESTAMP

Cart Item

Column	Type
cart_item_id	UUID
cart_id	UUID
item_id	UUID
quantity	INTEGER
price	DECIMAL

Order Database

Order Table

Column	Type
order_id	UUID
customer_id	UUID
restaurant_id	UUID
payment_id	UUID
order_status	VARCHAR
subtotal	DECIMAL
delivery_fee	DECIMAL
tax	DECIMAL
total_amount	DECIMAL
created_at	TIMESTAMP

Order Item

Column	Type
order_item_id	UUID
order_id	UUID
item_id	UUID
quantity	INTEGER
item_price	DECIMAL

Order Status

Status
Created
Confirmed
Preparing
Ready
Picked Up
On The Way
Delivered
Cancelled

Payment Database

Payment Table

Column	Type
payment_id	UUID
order_id	UUID
payment_method	VARCHAR
payment_status	VARCHAR
amount	DECIMAL
transaction_reference	VARCHAR

Driver Database

Driver Table

Column	Type
driver_id	UUID
first_name	VARCHAR
phone	VARCHAR
vehicle_type	VARCHAR
rating	DECIMAL
status	VARCHAR

Driver Location

Column	Type
location_id	UUID
driver_id	UUID
latitude	DECIMAL
longitude	DECIMAL
updated_at	TIMESTAMP

Driver locations are updated continuously.

Delivery Database

Delivery Table

Column	Type
delivery_id	UUID
order_id	UUID
driver_id	UUID
pickup_time	TIMESTAMP
delivered_time	TIMESTAMP
delivery_status	VARCHAR

Review Database

Review Table

Column	Type
review_id	UUID
customer_id	UUID
order_id	UUID
restaurant_rating	INTEGER
driver_rating	INTEGER
comments	TEXT

Promotion Database

Coupon

Column	Type
coupon_id	UUID
coupon_code	VARCHAR
discount_type	VARCHAR
discount_value	DECIMAL
expiry_date	TIMESTAMP

Entity Relationship Diagram

flowchart TD

Customer

Restaurant

Menu

Cart

Order

Payment

Driver

Delivery

Review

Coupon

Customer --> Cart

Customer --> Order

Restaurant --> Menu

Restaurant --> Order

Cart --> Order

Order --> Payment

Order --> Delivery

Driver --> Delivery

Order --> Review

Coupon --> Order

Order Placement Flow

flowchart LR

Customer

Customer --> Cart

Cart --> Checkout

Checkout --> Payment

Payment --> Order

Order --> Restaurant

Restaurant Preparation Flow

flowchart LR

Order

Order --> Accepted

Accepted --> Preparing

Preparing --> Ready

Ready --> Pickup

Delivery Flow

flowchart LR

Ready

Ready --> DriverAssigned

DriverAssigned --> Pickup

Pickup --> Customer

Customer --> Delivered

Review Flow

flowchart LR

Delivered

Delivered --> Rating

Rating --> Restaurant

Rating --> Driver

REST API Design

Customer APIs

Create Customer

POST /customers

Customer Profile

GET /customers/{id}

Update Profile

PUT /customers/{id}

Restaurant APIs

Nearby Restaurants

GET /restaurants

Restaurant Details

GET /restaurants/{id}

Restaurant Menu

GET /restaurants/{id}/menu

Cart APIs

Create Cart

POST /cart

Add Item

POST /cart/items

Update Quantity

PUT /cart/items/{id}

Remove Item

DELETE /cart/items/{id}

Order APIs

Create Order

POST /orders

Example Request

{
  "customerId":"CUS101",
  "restaurantId":"RES201",
  "paymentMethod":"CARD"
}

Example Response

{
  "orderId":"ORD90001",
  "status":"CREATED"
}

Order Details

GET /orders/{id}

Cancel Order

POST /orders/{id}/cancel

Payment APIs

Create Payment

POST /payments

Payment Status

GET /payments/{id}

Refund Payment

POST /payments/{id}/refund

Driver APIs

Nearby Drivers

GET /drivers/nearby

Update Driver Location

PUT /drivers/location

Driver Availability

PUT /drivers/status

Delivery APIs

Assign Driver

POST /deliveries/assign

Track Delivery

GET /deliveries/{id}

Complete Delivery

POST /deliveries/{id}/complete

Sequence Diagram

sequenceDiagram

Customer->>Gateway: Place Order

Gateway->>Cart: Validate Cart

Cart-->>Gateway: Success

Gateway->>Payment: Process Payment

Payment-->>Gateway: Success

Gateway->>Order: Create Order

Order->>Restaurant: New Order

Restaurant-->>Order: Accepted

Order-->>Customer: Order Confirmed

Event-Driven Architecture

Business events are published to Kafka.

flowchart LR

Order

Order --> Kafka

Payment --> Kafka

Restaurant --> Kafka

Delivery --> Kafka

Kafka --> Notification

Kafka --> Analytics

Kafka --> Reporting

Kafka Topics

Topic	Producer	Consumer
order-created	Order Service	Restaurant Service
order-confirmed	Restaurant Service	Delivery Service
payment-success	Payment Service	Order Service
payment-failed	Payment Service	Notification Service
food-preparing	Restaurant Service	Notification Service
food-ready	Restaurant Service	Delivery Service
driver-assigned	Delivery Service	Notification Service
driver-location-updated	Driver Service	Tracking Service
order-delivered	Delivery Service	Review Service
review-created	Review Service	Analytics Service

Sample Kafka Event

{
  "event":"ORDER_CREATED",
  "orderId":"ORD90001",
  "customerId":"CUS101",
  "restaurantId":"RES201",
  "amount":42.50,
  "timestamp":"2026-08-15T18:10:20Z"
}

Service Communication

Use synchronous communication for:

Customer authentication
Restaurant validation
Menu lookup
Payment authorization
Order status

Use asynchronous communication for:

Driver assignment
Notifications
Analytics
Reviews
Reporting
Recommendation updates

Data Consistency

Strong consistency is required for:

Order creation
Payment processing
Inventory updates
Driver assignment

Eventual consistency is acceptable for:

Notifications
Restaurant recommendations
Analytics
Reporting dashboards

Error Handling

Error	Solution
Duplicate Order	Idempotency Key
Payment Failure	Retry Payment
Restaurant Offline	Reject Order
Item Out of Stock	Update Cart
Driver Unavailable	Reassign Driver
Notification Failure	Retry via Kafka
GPS Update Delay	Use Last Known Location

Best Practices

Use a database per microservice.
Store menu images in object storage instead of relational databases.
Keep order history immutable after completion.
Publish business events through Kafka.
Make order APIs idempotent.
Track drivers independently from delivery workflows.
Maintain inventory separately from menu data.
Secure payment processing using tokenization.
Use UUIDs across distributed services.
Separate read and write workloads where appropriate.

Search, Driver Allocation, Geospatial Architecture & Advanced Workflows

In Part 2, we designed the low-level architecture, databases, REST APIs, and event-driven communication.

In this part, we'll design the advanced architecture required by enterprise food delivery platforms like Uber Eats, DoorDash, Swiggy, and Zomato.

Topics covered:

Restaurant Discovery
Search Architecture
Cart Workflow
Checkout Workflow
Payment Workflow
Restaurant Acceptance
Kitchen Workflow
Delivery Partner Allocation
Real-Time Driver Tracking
ETA Calculation
Order Tracking
Redis
Geospatial Indexing
CQRS
Saga Pattern
Recommendation Engine
Fraud Detection
Security
Multi-Region Deployment

Enterprise Architecture

flowchart LR

Customer

Customer --> Gateway

Gateway --> Search

Gateway --> Order

Gateway --> Payment

Gateway --> Delivery

Gateway --> Notification

Restaurant Discovery

Restaurant discovery is one of the highest-traffic features.

Users search using:

Current location
Cuisine
Restaurant name
Ratings
Delivery time
Price
Offers
Distance

Search Workflow

flowchart LR

Customer

Customer --> Search

Search --> Redis

Redis --> SearchDB

SearchDB --> Results

Search Ranking Factors

Factor	Importance
Distance	Very High
Restaurant Rating	High
Delivery Time	High
Availability	High
Cuisine Match	Medium
Sponsored Listing	Medium
Popularity	Medium

Restaurant Availability

Restaurants are filtered by:

Open hours
Delivery radius
Inventory availability
Driver availability
Temporary closures

Search Optimization

Use:

Elasticsearch
Redis Cache
Geospatial indexes
Search suggestions
Auto-complete

Cart Workflow

flowchart LR

Restaurant

Restaurant --> Menu

Menu --> Cart

Cart --> Coupon

Coupon --> Checkout

Cart Validation

Before checkout verify:

Restaurant is open
Food is available
Prices are current
Coupon is valid
Delivery address is serviceable
Minimum order value is satisfied

Checkout Workflow

flowchart LR

Checkout

Checkout --> Payment

Payment --> Order

Order --> Restaurant

Checkout Validation

Verify:

Inventory
Delivery fee
Taxes
Promotions
Wallet balance
Payment method
Restaurant status

Payment Workflow

flowchart LR

Customer

Customer --> Payment

Payment --> Gateway

Gateway --> Bank

Bank --> Success

Restaurant Acceptance

After payment:

Restaurant can

Accept
Reject
Timeout

Timeout automatically cancels the order after a configurable duration.

Restaurant Workflow

flowchart LR

Order

Order --> Accepted

Accepted --> Preparing

Preparing --> Ready

Kitchen Workflow

Kitchen operations:

Receive order
Queue preparation
Prepare food
Quality check
Pack food
Mark ready

Kitchen Queue

flowchart LR

Orders

Orders --> Queue

Queue --> Cooking

Cooking --> Packing

Packing --> Ready

Driver Allocation

Selecting the right delivery partner is one of the most critical parts of the platform.

Selection criteria:

Distance
Vehicle type
Driver rating
Current workload
Delivery history
Availability

Driver Assignment Flow

flowchart LR

Ready

Ready --> DriverSearch

DriverSearch --> Driver

Driver --> Accepted

Driver Assignment Algorithm

Example scoring:

Score

=

Distance

+

Driver Rating

+

Acceptance Rate

+

Current Load

+

ETA

The driver with the best overall score receives the order.

Real-Time Driver Tracking

Driver applications continuously send GPS updates.

Example interval:

Every 5 Seconds

Each update contains:

Latitude
Longitude
Speed
Direction
Timestamp

GPS Tracking

flowchart LR

Driver

Driver --> GPS

GPS --> Tracking

Tracking --> Customer

ETA Calculation

ETA depends on:

Current location
Restaurant preparation time
Traffic
Weather
Road closures
Driver speed

ETA Workflow

flowchart LR

Driver

Driver --> Traffic

Traffic --> ETA

ETA --> Customer

Order Tracking

Customers should see:

Order accepted
Preparing
Driver assigned
Driver arrived
Picked up
Near destination
Delivered

Order Tracking Flow

flowchart LR

Order

Order --> Preparing

Preparing --> Pickup

Pickup --> Delivery

Delivery --> Completed

Redis

Redis reduces database load.

Cache:

Restaurant profile
Popular menus
Coupons
Driver availability
Customer session
Search results

Recommended Cache TTL

Data	TTL
Restaurant Profile	30 Minutes
Popular Menu	15 Minutes
Coupons	10 Minutes
Customer Session	30 Minutes
Driver Availability	30 Seconds
Search Results	5 Minutes

Never Cache

Do not cache:

Active order state
Payment status
Inventory quantity
Driver earnings
Final settlement

Geospatial Indexing

Searching all drivers is inefficient.

Instead use geospatial indexing.

Supported technologies:

GeoHash
H3
QuadTree
PostGIS
Redis GEO

Geospatial Search

flowchart LR

Location

Location --> GeoIndex

GeoIndex --> Drivers

Drivers --> Closest

Driver Search Radius

Typical search:

2 Miles

↓

5 Miles

↓

10 Miles

Expand the radius only if no suitable drivers are found.

CQRS

Write Operations

Create order
Cancel order
Update driver
Complete delivery

Read Operations

Restaurant search
Order tracking
Driver tracking
Customer history

CQRS Architecture

flowchart LR

Customer

Customer --> CommandAPI

Customer --> QueryAPI

CommandAPI --> WriteDB

WriteDB --> Kafka

Kafka --> ReadDB

ReadDB --> QueryAPI

Saga Pattern

A food order spans multiple services.

Example workflow:

Validate restaurant
Reserve inventory
Process payment
Create order
Assign driver
Notify restaurant
Notify customer

Saga Workflow

flowchart TD

Order

Order --> Inventory

Inventory --> Payment

Payment --> Driver

Driver --> Notification

Compensation Example

Inventory reserved

↓

Payment failed

↓

Compensation:

flowchart LR

InventoryReserved

InventoryReserved --> PaymentFailed

PaymentFailed --> InventoryReleased

Recommendation Engine

Recommendations are based on:

Order history
Favorite cuisines
Location
Time of day
Restaurant ratings
Trending dishes

Recommendation Flow

flowchart LR

Customer

Customer --> Recommendation

Recommendation --> Restaurants

Fraud Detection

Detect:

Fake restaurants
Coupon abuse
Fake deliveries
Multiple account abuse
Wallet fraud
Payment fraud

Fraud Workflow

flowchart LR

Order

Order --> RiskEngine

RiskEngine --> Approved

RiskEngine --> Review

RiskEngine --> Rejected

Security

Protect:

Customer information
Driver information
Restaurant information
Payment tokens
GPS location

Use:

OAuth2
JWT
TLS 1.3
AES-256 Encryption
RBAC
API Rate Limiting

Notification Channels

Notify customers using:

Push Notification
SMS
Email
In-App Notification

Events include:

Order confirmed
Driver assigned
Food picked up
Driver nearby
Order delivered

Multi-Region Deployment

Global platforms deploy across multiple regions.

Objectives:

Low latency
High availability
Disaster recovery
Regulatory compliance

Multi-Region Architecture

flowchart LR

Users

Users --> RegionA

Users --> RegionB

RegionA --> DatabaseA

RegionB --> DatabaseB

DatabaseA --> Replication

Replication --> DatabaseB

Reliability Patterns

Implement:

Retry
Timeout
Circuit Breaker
Bulkhead
Rate Limiting
Dead Letter Queue
Outbox Pattern

These patterns improve resiliency while preventing cascading failures.

Performance Optimization

Optimize using:

Redis caching
Elasticsearch
Read replicas
Kafka partitions
Connection pooling
CDN for images
Async notifications

Best Practices

Keep order history immutable after delivery.
Cache frequently accessed restaurant and menu data.
Use geospatial indexing for nearby restaurant and driver searches.
Allocate drivers based on scoring instead of distance alone.
Coordinate distributed workflows using Saga Pattern.
Separate read and write workloads with CQRS.
Publish business events using Kafka.
Encrypt sensitive customer and location data.
Design services for horizontal scalability.
Continuously monitor ETA accuracy and delivery performance.

Production Deployment, Kubernetes, Observability, Disaster Recovery & Production Operations

In Part 3, we designed the advanced architecture, including restaurant discovery, geospatial indexing, driver allocation, CQRS, Saga Pattern, Redis, and multi-region deployment.

In this part, we'll focus on deploying and operating an enterprise-scale Food Delivery System in production.

Topics covered:

Production Deployment Architecture
Docker
Kubernetes
API Gateway
Service Discovery
Load Balancing
CI/CD Pipeline
Rolling Deployment
Blue-Green Deployment
Canary Deployment
Monitoring
Logging
Distributed Tracing
Alerting
Disaster Recovery
Performance Optimization
Cost Optimization
Production Operations

Production Goals

A production food delivery platform should provide:

99.99% availability
Low API latency
Real-time order tracking
High throughput
Zero order duplication
Fast driver allocation
Automatic recovery
End-to-end observability
Disaster recovery
Security by design

Enterprise Production Architecture

flowchart TD

Customers

Restaurants

Drivers

Customers --> DNS

Restaurants --> DNS

Drivers --> DNS

DNS --> CDN

CDN --> WAF

WAF --> LoadBalancer

LoadBalancer --> APIGateway

APIGateway --> Kubernetes

Kubernetes --> CustomerService

Kubernetes --> RestaurantService

Kubernetes --> OrderService

Kubernetes --> PaymentService

Kubernetes --> DriverService

Kubernetes --> DeliveryService

Kubernetes --> NotificationService

Infrastructure Stack

Layer	Technology
DNS	Route53 / Cloud DNS
CDN	CloudFront / Azure CDN
WAF	AWS WAF
Load Balancer	ALB / NGINX
API Gateway	Kong / Spring Cloud Gateway
Container Runtime	Docker
Orchestration	Kubernetes
Messaging	Kafka
Cache	Redis
Database	PostgreSQL
Search	Elasticsearch
Monitoring	Prometheus
Dashboards	Grafana
Logging	ELK / OpenSearch
Tracing	Jaeger / Zipkin

Docker

Each microservice is packaged into a Docker image.

Benefits:

Environment consistency
Immutable deployments
Faster delivery
Dependency isolation
Easy rollback

Sample Dockerfile

FROM eclipse-temurin:21-jre

WORKDIR /app

COPY target/order-service.jar app.jar

EXPOSE 8080

ENTRYPOINT ["java","-jar","app.jar"]

Kubernetes

Kubernetes manages:

Deployments
Pods
Services
Ingress
Auto scaling
Self-healing
Rolling updates
Failover

Kubernetes Architecture

flowchart TD

Users

Users --> Ingress

Ingress --> Gateway

Gateway --> CustomerPods

Gateway --> RestaurantPods

Gateway --> OrderPods

Gateway --> DriverPods

Gateway --> DeliveryPods

Gateway --> NotificationPods

Kubernetes Resources

Resource	Purpose
Pod	Application instance
Deployment	Replica management
Service	Internal communication
Ingress	External routing
ConfigMap	Configuration
Secret	Sensitive data
StatefulSet	Stateful applications
Horizontal Pod Autoscaler	Dynamic scaling

Namespace Strategy

Recommended namespaces

production

staging

uat

development

Benefits:

Environment isolation
Better security
Easier deployments
Resource governance

Service Discovery

Services communicate through logical DNS names.

Examples

customer-service

restaurant-service

order-service

payment-service

driver-service

delivery-service

Applications never depend on fixed IP addresses.

Internal Communication

flowchart LR

Gateway

Gateway --> Order

Order --> Payment

Payment --> Delivery

Delivery --> Notification

API Gateway

Responsibilities

Authentication
Authorization
SSL termination
Routing
Rate limiting
API aggregation
Request validation
Logging

Load Balancing

Traffic is distributed across healthy service instances.

flowchart TD

Clients

Clients --> LoadBalancer

LoadBalancer --> Pod1

LoadBalancer --> Pod2

LoadBalancer --> Pod3

Benefits

High availability
Fault tolerance
Better throughput
Lower response time

Horizontal Scaling

Increase pod count during:

Lunch rush
Dinner rush
Weekend traffic
Promotional campaigns

Example

10 Pods

↓

50 Pods

↓

150 Pods

Scaling Metrics

CPU usage
Memory usage
Orders per second
Driver allocation queue
Kafka consumer lag
Request latency

Vertical Scaling

Increase:

CPU
Memory
Storage

Recommended for:

PostgreSQL
Kafka Brokers
Redis
Elasticsearch

Scaling Strategy

Service	Scaling Need
API Gateway	Extremely High
Search Service	Extremely High
Order Service	Extremely High
Driver Service	Very High
Delivery Service	Very High
Restaurant Service	High
Notification Service	High
Review Service	Medium
Analytics Service	Medium

CI/CD Pipeline

Every deployment should follow an automated pipeline.

flowchart LR

Developer

Developer --> Git

Git --> Build

Build --> Test

Test --> SecurityScan

SecurityScan --> Docker

Docker --> Registry

Registry --> Kubernetes

Continuous Integration

Pipeline stages:

Checkout source
Compile
Unit tests
Integration tests
Static code analysis
Dependency scanning
Docker image creation
Push to registry

Continuous Delivery

Deployment Flow

Development

↓

QA

↓

UAT

↓

Performance Testing

↓

Security Testing

↓

Production Approval

↓

Production

Deployment Strategies

Rolling Deployment

flowchart LR

Old

Old --> Mixed

Mixed --> New

Recommended for:

Review Service
Analytics
Notification Service

Blue-Green Deployment

flowchart LR

Users

Users --> Blue

Blue --> Green

Recommended for:

Order Service
Payment Service
Delivery Service

Canary Deployment

Traffic distribution

5%

↓

20%

↓

50%

↓

100%

Recommended for:

Recommendation Engine
Search improvements
Driver allocation algorithm
ETA prediction model

Monitoring Architecture

flowchart LR

Applications

Applications --> Metrics

Applications --> Logs

Applications --> Traces

Metrics --> Prometheus

Prometheus --> Grafana

Logs --> ELK

Traces --> Jaeger

Infrastructure Metrics

Monitor:

CPU
Memory
Disk
JVM Heap
Network latency
Kafka consumer lag
Database connections
Redis hit ratio

Business Metrics

Track:

Orders per minute
Active restaurants
Active drivers
Delivery success rate
Order completion rate
Average delivery time
Average preparation time
Driver utilization

Customer Experience KPIs

Monitor:

Search latency
Checkout success rate
Payment success rate
Driver assignment time
ETA accuracy
Order cancellation rate
Customer satisfaction score

Golden Signals

Signal	Description
Latency	API response time
Traffic	Requests per second
Errors	Failed requests
Saturation	Resource utilization

Logging Strategy

Every request should include:

Trace ID
Correlation ID
Order ID
Customer ID
Restaurant ID
Driver ID
Request ID
Timestamp
Response time

Sample Structured Log

{
  "traceId":"TR100100",
  "orderId":"ORD80001",
  "customerId":"CUS101",
  "restaurantId":"RES200",
  "driverId":"DRV501",
  "status":"DELIVERED",
  "responseTime":38
}

Distributed Tracing

A single order travels through multiple services.

flowchart LR

Gateway

Gateway --> Order

Order --> Payment

Payment --> Restaurant

Restaurant --> Delivery

Delivery --> Notification

Every service propagates the same Trace ID.

Health Checks

Expose Spring Boot Actuator endpoints.

GET /actuator/health

GET /actuator/liveness

GET /actuator/readiness

These endpoints allow Kubernetes to automatically restart unhealthy pods.

Alerting Strategy

Condition	Severity
Order Failure > 2%	Critical
Payment Failure > 2%	Critical
Driver Assignment Delay > 2 Minutes	Critical
ETA Error > 10 Minutes	Warning
Kafka Consumer Lag	Warning
Database Replication Failure	Critical
Pod CrashLoop	Critical
CPU > 90%	Warning

Backup Strategy

Protect business data using:

Hourly incremental backups
Daily full backups
Weekly archive
Cross-region replication
Immutable backup storage

Regular restore testing is essential.

Disaster Recovery

The platform should survive:

Cloud region outage
Database failure
Kafka cluster failure
Kubernetes cluster failure
Payment provider outage
GPS provider outage

Disaster Recovery Architecture

flowchart TD

PrimaryRegion

PrimaryRegion --> DatabaseA

PrimaryRegion --> KafkaA

DatabaseA --> Replication

KafkaA --> Replication

Replication --> SecondaryRegion

SecondaryRegion --> DatabaseB

SecondaryRegion --> KafkaB

Recovery Objectives

Objective	Target
Recovery Point Objective (RPO)	Near Zero
Recovery Time Objective (RTO)	Less than 30 Minutes

Production Failure Scenarios

Restaurant Service Down

Recovery:

Route traffic to healthy instances
Retry failed requests
Queue new orders temporarily

Driver Service Failure

Recovery:

Preserve active deliveries
Retry assignment
Notify operations team

Payment Provider Failure

Recovery:

Retry payment
Switch to backup payment gateway
Queue pending payments
Notify customers

Kafka Failure

Recovery:

Retry producers
Retry consumers
Dead Letter Queue
Cluster replication

Kubernetes Node Failure

Recovery:

Restart failed pods
Reschedule workloads
Redistribute traffic

Regional Outage

Recovery:

DNS failover
Activate standby region
Promote replica databases
Resume order processing

Performance Optimization

Improve performance using:

Redis caching
Elasticsearch
Database indexing
Read replicas
Kafka partitioning
Connection pooling
CDN for images
Async notifications

Cost Optimization

Reduce infrastructure cost through:

Horizontal Pod Autoscaler
Reserved instances
Spot instances for batch jobs
Log archival
Kafka retention optimization
Storage lifecycle management
Right-sized Kubernetes nodes

Security Operations

Production security includes:

TLS 1.3
Mutual TLS
Kubernetes Network Policies
Secret rotation
Image vulnerability scanning
RBAC
Runtime threat detection
Zero Trust networking

Production Readiness Checklist

Area	Ready
Docker	✓
Kubernetes	✓
Security Review	✓
CI/CD	✓
Monitoring	✓
Logging	✓
Distributed Tracing	✓
Auto Scaling	✓
Backup Validation	✓
Disaster Recovery	✓
Alerting	✓
Rollback Strategy	✓

Production Operations

Operations teams should continuously monitor:

Order success rate
Payment success rate
Driver assignment latency
Delivery completion time
ETA prediction accuracy
Restaurant acceptance rate
Kafka consumer lag
Search latency
Infrastructure utilization
Operational cost

Best Practices

Deploy services independently.
Use Blue-Green deployments for critical order and payment services.
Continuously monitor customer experience metrics.
Propagate Trace IDs across all microservices.
Scale stateless services horizontally.
Test disaster recovery regularly.
Encrypt all sensitive customer and payment data.
Rotate secrets automatically.
Implement automated rollback strategies.
Perform regular load and chaos testing.

Real Production Challenges

Large food delivery platforms process millions of orders every day.

Typical challenges include:

Dinner rush traffic
Flash sales
Driver shortages
Restaurant outages
GPS inaccuracies
Payment failures
Inventory inconsistencies
Traffic congestion
Regional outages
Fraud

Challenge 1 — Dinner Rush

Peak hours typically occur between:

11 AM – 2 PM

6 PM – 9 PM

Traffic may increase by 5–10× compared to normal periods.

Dinner Rush Architecture

flowchart LR

Customers

Customers --> Gateway

Gateway --> OrderPods

Gateway --> Kafka

Kafka --> Restaurant

Kafka --> Driver

Solutions:

Horizontal auto scaling
Kafka partitioning
Redis caching
Queue-based processing
Async notifications

Challenge 2 — Flash Sales

Examples:

50% Off Pizza
Free Delivery Weekend
National Holidays
Sports Events

Problems:

Search overload
Cart spikes
Coupon validation load
Database contention

Flash Sale Strategy

flowchart LR

Customers

Customers --> CDN

CDN --> Redis

Redis --> Services

Best practices:

Cache restaurant menus
Cache promotions
Rate limiting
Queue checkout requests
Auto scale API Gateway

Challenge 3 — Driver Shortage

Demand often exceeds supply.

Example:

500 Orders

↓

180 Available Drivers

Strategies:

Increase delivery fee
Expand search radius
Batch deliveries
Offer surge incentives
Delay ETA dynamically

Driver Allocation

flowchart LR

Orders

Orders --> DriverPool

DriverPool --> BestDriver

BestDriver --> Delivery

Selection considers:

Distance
Rating
Acceptance rate
Current workload
Vehicle type

Challenge 4 — Restaurant Downtime

Restaurants may become unavailable because of:

Kitchen overload
Inventory shortage
Internet outage
Power failure

Recovery:

Mark temporarily unavailable
Hide from search
Stop accepting new orders
Notify affected customers

Challenge 5 — Payment Failures

Reasons:

Bank timeout
Card declined
Wallet unavailable
Gateway outage

Recovery Strategy:

Retry safely
Idempotency keys
Backup payment provider
Customer notification

Payment Workflow

flowchart LR

Customer

Customer --> Payment

Payment --> GatewayA

GatewayA --> Success

GatewayA --> GatewayB

Challenge 6 — GPS Failure

GPS problems include:

Weak signal
Urban canyons
Tunnel coverage
Device battery saver

Solutions:

Last known location
Cell tower approximation
Route prediction
Customer updates

Challenge 7 — ETA Drift

Estimated delivery time changes because of:

Traffic
Weather
Restaurant delays
Driver reassignment
Road closures

ETA Pipeline

flowchart LR

GPS

GPS --> Traffic

Traffic --> ETA

ETA --> Customer

Challenge 8 — Route Optimization

Drivers may receive multiple deliveries.

Objectives:

Minimize travel distance
Reduce delivery time
Increase completed deliveries
Lower fuel cost

Factors:

Distance
Traffic
Order priority
Food preparation time

Challenge 9 — Inventory Mismatch

Possible causes:

Simultaneous ordering
Manual updates
Restaurant delays

Solutions:

Inventory reservation
Optimistic locking
Automatic reconciliation

Challenge 10 — Fraud

Examples:

Fake restaurants
Fake customers
Fake drivers
Coupon abuse
Referral abuse
Payment fraud

Fraud Engine checks:

Device fingerprint
IP reputation
Velocity limits
Location anomalies
Historical behavior

Scalability Strategy

flowchart TD

Gateway

Gateway --> Search

Gateway --> Order

Gateway --> Payment

Gateway --> Delivery

Gateway --> Notification

Gateway --> Analytics

Scale each service independently.

Database Scaling

Techniques:

Read replicas
Database partitioning
Connection pooling
Index optimization
Archive historical orders

flowchart LR

Application

Application --> PrimaryDB

PrimaryDB --> Replica1

PrimaryDB --> Replica2

Kafka Scaling

Use:

Topic partitioning
Consumer groups
Horizontal consumers

Example:

Order Topic

↓

128 Partitions

↓

512 Consumers

Redis Scaling

flowchart LR

Application

Application --> RedisCluster

RedisCluster --> Node1

RedisCluster --> Node2

RedisCluster --> Node3

Ideal for:

Restaurant cache
Menu cache
Customer session
Search cache
Coupon cache
Driver availability

Cost Optimization

Reduce infrastructure costs using:

Kubernetes auto scaling
Spot instances for batch jobs
CDN for images
Log archival
Kafka retention policies
Storage lifecycle management
Right-sized databases

Reliability Patterns

Use:

Retry
Timeout
Circuit Breaker
Bulkhead
Rate Limiting
Dead Letter Queue
Outbox Pattern

These patterns improve resilience and prevent cascading failures.

Architecture Trade-offs

SQL vs NoSQL

SQL	NoSQL
ACID transactions	Flexible schema
Orders	Analytics
Payments	Recommendations

REST vs Event-Driven

REST	Event-Driven
Immediate response	Asynchronous
Easier debugging	Loose coupling
Request/Response	Event streaming

Polling vs WebSocket

Polling	WebSocket
Simpler	Real-time
Higher network overhead	Persistent connection
Order status refresh	Live driver tracking

Single Driver vs Batch Delivery

Single Delivery	Batch Delivery
Faster delivery	Better efficiency
Higher cost	Lower operational cost
Better customer experience	Better driver utilization

High availability and disaster recovery.

Common Production Issues

Issue	Solution
Duplicate Orders	Idempotency Keys
Payment Timeout	Retry + Backup Gateway
Driver Shortage	Expand Search Radius
Restaurant Offline	Hide From Search
Inventory Conflict	Reservation System
Kafka Consumer Lag	Scale Consumers
High Search Latency	Redis + Elasticsearch
ETA Drift	Dynamic Recalculation
Pod CrashLoop	Kubernetes Self-Healing
Region Failure	Active-Active Deployment

Production Readiness Checklist

Area	Ready
Docker	✓
Kubernetes	✓
Security Review	✓
Load Testing	✓
Monitoring	✓
Logging	✓
Distributed Tracing	✓
Auto Scaling	✓
Backup Validation	✓
Disaster Recovery	✓
Alerting	✓
Rollback Strategy	✓

Best Practices

Keep completed orders immutable.
Use event-driven communication between services.
Cache frequently accessed restaurant and menu data.
Apply geospatial indexing for location-based searches.
Make checkout APIs idempotent.
Use Saga Pattern for distributed transactions.
Scale stateless services independently.
Continuously monitor ETA accuracy.
Encrypt customer and payment information.
Regularly test disaster recovery procedures.

Common Design Mistakes

Using a Shared Database

Creates tight coupling and limits scalability.

Ignoring Geospatial Queries

Distance calculations become slow at scale.

Synchronous Notifications

Notifications should be asynchronous to avoid delaying order processing.

Storing Images in Relational Databases

Store images in object storage instead.

No Driver Reassignment

Drivers may cancel or become unavailable. Always support reassignment.

Missing Idempotency

Retrying checkout requests can create duplicate orders.

Food Delivery System Design Interview Questions

1. How would you design Uber Eats?

Use microservices for customers, restaurants, menus, orders, payments, drivers, deliveries, and notifications connected through Kafka-based event-driven communication.

2. How do you find nearby restaurants?

Use geospatial indexing with technologies such as Redis GEO, PostGIS, GeoHash, or H3.

3. How do you assign drivers?

Evaluate distance, driver rating, acceptance rate, availability, workload, and estimated arrival time.

4. How do you prevent duplicate orders?

Use idempotency keys, unique order identifiers, and safe retry mechanisms.

5. Why use Kafka?

To decouple order processing, driver assignment, notifications, analytics, and reporting.

6. What should be cached?

Restaurant profiles, menus, coupons, search results, customer sessions, and driver availability.

7. What should never be cached?

Payment state, inventory quantity, active orders, and settlement information.

8. Why use CQRS?

To separate read-heavy search and tracking operations from transactional order processing.

9. Why use Saga Pattern?

To coordinate inventory reservation, payment, order creation, driver assignment, and notifications across multiple services.

10. How do you calculate ETA?

Combine driver location, restaurant preparation time, traffic conditions, weather, and historical travel data.

11. How do you track drivers?

Use periodic GPS updates, WebSockets, geospatial indexes, and event streaming.

12. How do you support flash sales?

Auto scale services, cache menus, use Redis, queue requests, and apply rate limiting.

13. How do you handle payment failures?

Retry safely, switch to backup gateways, and notify customers.

14. What happens if a restaurant rejects an order?

Cancel the order, initiate a refund if payment was captured, and notify the customer.

15. How do you manage inventory?

Reserve inventory during checkout and release it on cancellation or payment failure.

16. How do you optimize restaurant search?

Use Elasticsearch, Redis, geospatial indexes, and personalized ranking.

17. How do you detect fraud?

Analyze behavioral patterns, device fingerprints, velocity limits, payment history, and location anomalies.

18. How do you reduce delivery time?

Improve ETA prediction, optimize routes, batch deliveries intelligently, and allocate drivers efficiently.

19. How do you support scheduled orders?

Store future orders separately and trigger preparation workflows based on delivery time.

20. How do you handle driver cancellations?

Reassign another nearby driver while keeping customers informed.

21. Which metrics should be monitored?

Order success rate, payment success rate, driver assignment latency, ETA accuracy, and delivery completion rate.

22. How do you scale globally?

Deploy across multiple regions using database replication, DNS failover, and region-aware routing.

23. Why use Redis?

To reduce database load and provide low-latency access to frequently used data.

24. Why use Kubernetes?

For automated deployments, scaling, self-healing, and service orchestration.

25. How do you secure customer data?

Use OAuth2, JWT, TLS 1.3, AES-256 encryption, RBAC, and secret management.

26. How do you improve customer experience?

Provide accurate ETAs, real-time tracking, proactive notifications, and fast customer support.

27. What causes ETA drift?

Traffic congestion, weather, restaurant delays, driver reassignment, and GPS inaccuracies.

28. Which deployment strategy is safest?

Blue-Green or Canary deployments with automated rollback.

29. How do you improve driver utilization?

Batch nearby deliveries, optimize routing, and intelligently balance workloads.

30. What is the most important design principle?

Build loosely coupled, event-driven microservices that prioritize reliability, scalability, and an excellent customer experience.

Food Delivery Architecture Cheat Sheet

Area	Recommended Solution
Architecture	Microservices
API Style	REST + Event-Driven
Messaging	Kafka
Cache	Redis
Database	PostgreSQL
Search	Elasticsearch
Geospatial	GeoHash / H3 / Redis GEO
Workflow	Saga Pattern
Read Optimization	CQRS
Authentication	OAuth2 + JWT
Deployment	Kubernetes
Monitoring	Prometheus + Grafana
Logging	ELK / OpenSearch
Tracing	Jaeger / Zipkin
Object Storage	Cloud Object Storage
Disaster Recovery	Active-Active Multi-Region

Complete Enterprise Food Delivery Architecture

flowchart TD

Customer

Restaurant

Driver

Customer --> Gateway

Restaurant --> Gateway

Driver --> Gateway

Gateway --> AuthenticationService

Gateway --> SearchService

Gateway --> RestaurantService

Gateway --> MenuService

Gateway --> CartService

Gateway --> OrderService

Gateway --> PaymentService

Gateway --> DriverService

Gateway --> DeliveryService

Gateway --> NotificationService

Gateway --> ReviewService

Gateway --> PromotionService

OrderService --> Kafka

PaymentService --> Kafka

RestaurantService --> Kafka

DeliveryService --> Kafka

Kafka --> AnalyticsService

Kafka --> RecommendationService

Kafka --> ReportingService

SearchService --> SearchDB

OrderService --> OrderDB

PaymentService --> PaymentDB

DeliveryService --> DeliveryDB

Final Summary

Designing a modern Food Delivery System requires much more than creating and delivering orders. The platform must coordinate customers, restaurants, delivery partners, payment providers, mapping services, and recommendation engines while maintaining high availability, low latency, and real-time responsiveness.

Throughout this five-part series, we designed a production-ready architecture covering business requirements, microservices, database design, geospatial search, intelligent driver allocation, payment processing, Kubernetes deployment, observability, disaster recovery, and production operations. By combining Java, Spring Boot, Kafka, Redis, Elasticsearch, CQRS, Saga Pattern, and cloud-native architecture, organizations can build highly scalable food delivery platforms capable of processing millions of orders every day.

Key Takeaways

✅ Design independent microservices with database-per-service.
✅ Use geospatial indexing for restaurant and driver discovery.
✅ Coordinate distributed workflows with Saga Pattern.
✅ Cache search and menu data using Redis.
✅ Stream business events through Kafka.
✅ Use CQRS for search and tracking workloads.
✅ Scale services independently during peak traffic.
✅ Continuously monitor ETA accuracy and operational KPIs.
✅ Secure customer, payment, and location data.
✅ Build resilient, cloud-native systems with Kubernetes and multi-region deployment.

Food Delivery System Design

Learning Objectives

What is a Food Delivery System?

Business Model

Primary Actors

Customer Journey

Restaurant Journey

Delivery Partner Journey

Functional Requirements

Non-Functional Requirements

Capacity Estimation

Storage Estimation

Core Business Concepts

Restaurant

Menu

Cart

Order

Delivery

Payment

Ratings & Reviews

Order Lifecycle

Delivery Lifecycle

High-Level Architecture

Enterprise Architecture

Core Microservices

Service Responsibilities

Customer Service

Restaurant Service

Menu Service

Search Service

Cart Service

Order Service

Driver Service

Delivery Service

Payment Service

Order Flow

Restaurant Workflow

Driver Workflow

Notification Flow

Security Requirements

Compliance

High Availability Goals

Design Principles

Low-Level Architecture, Database Design, REST APIs & Event-Driven Architecture

Low-Level Architecture

Database Per Service

Database Architecture

Customer Database

Customer Table

Customer Address

Restaurant Database

Restaurant Table

Restaurant Schedule

Menu Database

Menu Category

Menu Item

Menu Add-on

Inventory Database

Inventory Table

Cart Database

Cart

Cart Item

Order Database

Order Table

Order Item

Order Status

Payment Database

Payment Table

Driver Database

Driver Table

Driver Location

Delivery Database

Delivery Table

Review Database

Review Table

Promotion Database

Coupon

Entity Relationship Diagram

Order Placement Flow

Restaurant Preparation Flow