How Meituan’s O2O Supply Chain Architecture Overcame Scaling Challenges

1 What Is a Supply Chain

In the fast‑changing O2O battlefield, Meituan’s success relies on a hidden technical team that builds the supply chain. The supply chain (SCP) digitizes agreements between the platform and merchants, turning paper contracts into electronic projects that users can view and purchase via the app or website.

These projects involve two key steps: refining the plan so consumers see detailed descriptions, prices, and restrictions, and reviewing the plan for legal and financial validity. Once completed, users can initiate a purchase, and the merchant fulfills the promised service.

The traditional group‑buying process starts with a Business Development (BD) person initiating a deal, signing a contract, entering details into a portal, and submitting for headquarters approval. After approval, the CMS packages the content for various C‑end channels, completing the project.

Beyond traditional group‑buying, Meituan’s O2O expands into hotels, travel, food delivery, breakfast, etc., each with varying standardization levels, posing new challenges for the supply‑chain system.

2 Supply‑Chain System Challenges

2.1 Complex Fine‑Grained Structured Data

Different O2O categories require vastly different attribute sets. For example, a restaurant hot‑pot order may involve around 100 attributes (cuisine, number of diners, package options, purchase notes, legal terms, etc.). This granularity is needed to serve both B‑end (BD efficiency) and C‑end (searchability) requirements and to adapt to rapidly changing channel demands.

2.2 Flexible and Varied Sales Modes

Products like hotel rooms have multiple selling options (breakfast included, room type, holiday pricing, etc.). Recording each variation separately would cause exponential growth in entry time. The system must support “record once, sell many” to keep BD workload manageable.

2.3 Dynamic Category and Attribute Adjustments

New sub‑categories (e.g., self‑service dining with Wi‑Fi, parking) or splits (Chengdu vs. Chongqing hot‑pot) require rapid UI and storage changes. The supply‑chain must allow zero‑code configuration for such adjustments.

2.4 Configurable Review Workflow

Different business channels need distinct approval rules. For new “buy‑now” services, only data consistency checks are required, while traditional group‑buying demands city‑level preliminary review followed by headquarters processing. The workflow must be dynamically configurable to reflect real‑time business changes.

3 Facing the Challenges

3.1 Building an O2O Service Model

Meituan transitioned from ad‑hoc development to a structured architecture with a “product center” that abstracts services (e.g., king‑size bed, breakfast, Wi‑Fi) into reusable units. These units map to sales‑side rules, consumption‑side rules, and pricing rules, collectively called SKU attributes, enabling flexible product generation.

3.2 Event‑Driven Decoupling

Introducing a workflow engine decouples business logic from the core supply‑chain system. Different channels can define their own approval nodes, participants, and routing, all configurable at runtime. Process data is now captured by the workflow, freeing the supply‑chain to focus on core functionality.

3.3 Automating Everything

3.3.1 Project 908

To reduce order‑entry cost during traffic spikes, Meituan split the supply‑chain process into multiple stages, each with tailored automation. By introducing “no‑review” and “no‑write” steps, they achieved a 90% cost reduction and an 8‑fold efficiency boost, dubbed Project 908.

3.3.2 Ongoing Automation

Project 908 evolved into a broader “automation‑first” mindset. Today, the supply‑chain uses workflow for repeatable reviews and an attribute center for dynamic category extensions, allowing business users to configure new attributes in minutes instead of days of development.

4 Achievements

4.1 Faster Delivery

For the “discount checkout” feature, the end‑to‑end supply‑chain development effort dropped from 30 person‑days to 5 person‑days, covering merchant onboarding, contract customization, data storage, and multi‑channel integration.

4.2 Cost Reduction & Efficiency

After eliminating manual review and writing, the dedicated review team (≈100 people) was dissolved, and with a 1000% order volume increase, the per‑order cost fell by over 90%.

5 Summary

From a technical perspective, the order‑entry flow works as follows: a BD initiates a request; the backend renders a Dynamic Form (DF) based on the channel and category; the request passes through the Attribute Center (AC) for validation, then is transformed for the Product Center; the finalized data is stored, and the Gravity scheduler triggers review tasks. Changes are recorded in the Change Center, also reviewed via Gravity. Once approved, the CMS assembles the final content using dynamic templates for various C‑end channels. The system follows an MVC pattern: Model (Product & Change Centers), View (Dynamic Forms & Templates), and Control (Attribute Center & Workflow), achieving high‑availability and automation.