Meituan Group Order System: Optimization, Sharding, and Service‑Oriented Refactoring

Meituan's group‑buy order system supports hundreds of millions of users. In early 2015 the daily order volume was 4‑5 million, peaking at 8 million during the Qixi festival.

Goal : Improve stability for a high‑traffic S‑level online service, especially during peak events, by identifying bottlenecks and implementing reliable, high‑performance solutions.

Optimization Approach : The team tackled the system step‑by‑step, focusing on storage, transmission, and architecture.

1. Storage Optimization

The original system suffered from strong coupling with other services, a monolithic codebase shared by >50 developers, and numerous single‑point failures (e.g., a single auto‑increment table for order IDs). The team applied both vertical and horizontal sharding:

Vertical sharding: moved non‑order tables out of the order database.

Horizontal sharding: eliminated the ID‑allocation single point by replacing one auto‑increment table with 100 parallel tables. Order IDs are derived from the user ID (e.g., order_id = userid_mod * 100 + userid_mod), allowing deterministic routing without an extra lookup table.

Images illustrate the 100‑table ID allocation and the user‑mod‑100 sharding scheme.

2. Transmission Optimization

The PHP‑based order service opened a new DB connection for every request, leading to connection exhaustion during traffic spikes. Database IPs were hard‑coded, making failover manual and slow (MTTR measured in hours).

The solution introduced a connection‑pool middleware (Atlas) provided by the DBA team. Atlas manages a stable pool of connections, supports automatic read/write splitting, and enables hot‑switching of database instances without code changes. Monitoring graphs show a dramatic reduction in per‑second new connections after Atlas deployment.

3. Architecture Optimization

Even after storage and transmission improvements, the monolithic repository and full‑deployment model remained problematic. The team adopted a micro‑service strategy, guided by three prerequisites:

DevOps culture – services must be observable, discoverable, and manageable.

Service evolution – boundaries are continuously refined.

Team‑architecture alignment – Conway’s law dictates that service boundaries match team structures.

The order system was split into three core domains: order placement, order query, and coupon issuance. Each domain received a two‑layer design (foundation layer handling data access, and a front layer handling business logic). Separate instances were deployed for normal traffic and promotional spikes, with distinct URIs to achieve physical isolation.

Message‑queue reliability was enhanced by deploying two independent queues (L and W) with a 10‑second delay queue for fallback processing. The coupon service first acknowledges the message, attempts issuance, and if it fails, the secondary queue retries with additional compensation logic (e.g., automatic refunds after 30 minutes).

Stability Guarantees

Post‑refactoring, the system incorporates:

Isolated development and testing environments for each micro‑service.

Blue‑green deployments for zero‑downtime releases.

Multi‑datacenter deployment (2:1 ratio) for disaster tolerance.

Complete removal of single points (database master, message queue) using sharding, dual‑cluster designs, and Databus replication.

Automatic degradation via Hystrix circuit breakers.

Comprehensive monitoring with centralized logging, Elasticsearch search, and Falcon alerts.

The refactored architecture successfully handled high‑traffic events such as the Qixi festival, delivering stable performance and easier iterative development.