How Meituan Scaled Its Food‑Delivery Order System to Millions of Daily Orders

Introduction

Since the first order in September 2013, Meituan Waimai has grown from a few daily orders to over 5 million orders per day, expanding from a single‑item service to a full‑category platform. The rapid increase in order volume and complexity has driven continuous evolution of the order system.

Food Delivery Order Business

The business demands high real‑time performance: an order must be placed, prepared, delivered, and confirmed within about one hour. Order volume peaks during lunch and dinner, creating intense, time‑bound load spikes.

Order System Prototype

In the early stage, the team prioritized flexibility and rapid iteration, packaging order functionality into a shared JAR that could be used by multiple services.

Independent Order System

By April 2014, daily orders reached 100,000 and continued to rise, prompting a split of the order system into an independent service to avoid interference with other business modules.

High‑Performance, High‑Availability, High‑Stability Order System

After isolation, the system handled millions of orders, but edge cases (e.g., payment success messages lost) exposed reliability gaps, leading to further upgrades.

Performance Optimization

Asynchrony

Operations that do not require immediate feedback are moved to asynchronous processing via thread pools or message queues, reducing request latency.

Parallelism

Independent sub‑tasks such as fetching store, dish, and user information are executed in parallel, shortening order‑placement time.

Caching

Pre‑computed data like first‑order discounts or delivery‑fee reductions are cached to avoid costly real‑time calculations.

Consistency Optimization

Retry / Idempotence

Operations such as refunds are retried with delayed jobs and made idempotent to guarantee eventual success.

Two‑Phase Commit (2PC)

Distributed transactions (e.g., stock reservation, coupon deduction) use 2PC to ensure atomicity across services.

High Availability

Availability is achieved by making each component—storage (MySQL, ES), middleware, and service layer—highly available. The service layer uses Hystrix with isolated thread pools, timeouts, fallbacks, and circuit breaking.

Scalable Order System

Scalability focuses on the storage layer: MySQL sharding (database and table partitioning) and Redis/Tair caching. Orders are stored redundantly by order‑ID, user‑ID, and shop‑ID across 100 tables in four databases.

Complex queries not covered by the partition keys are served by Elasticsearch, which receives order data via a databus and leverages sharding for scalability.

Intelligent Operations

Operations evolved from manual troubleshooting to automated, intelligent monitoring with pre‑, during‑, and post‑incident measures: regular online stress tests, health checks, full‑link logging, real‑time dashboards, alerting, and SOPs.

These practices reduce human effort, improve incident response speed, and ensure the order system remains reliable as traffic grows.