How to Build a Scalable Food Delivery System: Architecture, High Concurrency, and Real‑Time Dispatch

Introduction

Backend developers often wonder how to handle millions of orders during peak periods, calculate optimal rider routes, and manage user complaints when building a food‑delivery system.

Overall Architecture: The “Five Organs” of a Delivery System

The system must satisfy three core roles—users (order/track), merchants (accept/order), and riders (grab/deliver)—and adopts a layered, micro‑service design consisting of a foundation component layer, core service layer, business capability layer, and access layer, supported by monitoring and operations.

1.1 Architecture Diagram

1.2 Key Components Details

(1) Access Layer: The “Gatekeeper”

API Gateway : routing requests to order or merchant services, preventing service chaos.

Rate Limiting : token‑bucket algorithm limits per‑user QPS during lunch and dinner peaks.

Authentication : JWT for users, OAuth2.0 for merchants and riders.

Load Balancing : Nginx + LVS with DNS region routing directs users to the nearest data center.

Gray Release : canary rollout using user ID hash to split 10% of users for new features.

(2) Core Service Layer: The “Heart”

Order Service : manages the full order lifecycle—creation, state transitions, and queries, caching recent orders in Redis.

Merchant Service : handles merchant onboarding, store info, product management, and order acceptance, using MySQL sharding by merchant ID.

Rider Service : includes dispatch (smart and grab modes), route planning via Gaode/Baidu APIs, and real‑time rider status.

User Service : stores user profiles, login sessions, and address geocoding for distance calculations.

(3) Business Capability Layer: The “Add‑ons”

Marketing Service : implements discounts, coupons, group buying, and validates promotional rules.

Payment Service : integrates WeChat Pay/Alipay, handles callbacks and payment exceptions.

Message Service : sends notifications to users, merchants, and riders via SMS and app push.

(4) Infrastructure Layer: The “Foundation”

Storage : MySQL master‑slave with sharding, Redis cluster for hot data, OSS/S3 with CDN for images.

Message Queue : Kafka/RocketMQ decouples services, buffering order requests during spikes.

Map Component : geocoding, distance calculation, and real‑time route planning.

Real‑time Compute : Flink processes rider load, order timeout alerts, and sales statistics.

Core Functional Flow: From Order to Delivery

2.1 User Order – Precise Calculation within 10 seconds

Product Validation : check stock and business hours via merchant service.

Address Validation : ensure delivery address is within service radius using map API.

Price Calculation : apply promotions with the formula

商品总价 - 满减优惠 - 优惠券 - 红包 + 配送费 - 会员红包

.

Order Generation : generate a unique order ID (timestamp + user ID suffix + random) and write to order tables.

Message Notification : publish order events to Kafka; message service pushes notifications to user and merchant.

Key Technologies : distributed transaction TCC for consistency, Redis cache pre‑warming for fast price lookup.

2.2 Smart Dispatch – Faster Than a Rider

Three steps: filter riders (online, within 5 km, low load, high on‑time rate), compute a cost using a greedy algorithm (travel time + risk of other orders timing out), and notify the selected rider while updating statuses. If the smart system fails, fallback to grab mode.

Key Technologies : rider location stored in Redis refreshed every 3 seconds, dispatch degradation to grab mode.

2.3 Order Tracking – Real‑time Rider Position

Rider app reports latitude/longitude to Redis every 3 seconds; order service reads the latest position every 5 seconds, calculates ETA, and the frontend polls the tracking API to render the rider on a map.

Key Technologies : API rate limiting with Redis, graceful degradation when map API is unavailable.

Technical Challenges and Solutions

3.1 Peak‑time High Concurrency

During lunch and dinner peaks (11:30‑13:00, 18:00‑20:00) order volume can reach ten times normal levels. Solutions include front‑end rate limiting, Kafka buffering, Kubernetes auto‑scaling of order and merchant services, and multi‑level caching (frontend, Redis, DB read‑write split).

3.2 Real‑time Rider Location Updates

Millions of riders report positions every 3 seconds, resulting in up to 300 k updates per second. The system writes updates to Redis, then Flink asynchronously syncs them to a time‑series database (InfluxDB/Prometheus) for historical queries, with a 5‑minute TTL in Redis to clean offline riders.

3.3 Order Timeout and Exceptions

Flink monitors order states and triggers tiered alerts: first‑level for merchant acceptance timeout, second‑level for rider pickup delay, third‑level for delivery delay. Automated actions include SMS nudges, re‑dispatching, and customer‑service escalation with compensation.

Conclusion

By decomposing vague requirements into concrete modules, selecting appropriate tools (Redis + Kafka for high concurrency, greedy algorithm for dispatch, Flink for real‑time monitoring), and providing fallback mechanisms, building a robust food‑delivery system becomes manageable.

When someone says “let’s build a delivery system”, you can confidently answer: “orders are sharded, dispatch uses a greedy algorithm, and high concurrency is handled by Redis + Kafka”.