How Meituan Built a Scalable Rule Engine to Boost Efficiency

In July 2016 Meituan’s business entered its second half, requiring optimization of experience, efficiency, and cost; the technical team needed to adapt to these changes.

Meituan Waimai’s CRM business matured, and rule‑based requirements accounted for half of all demands. Developers found rule development tedious and low‑value, prompting a search for a more efficient solution.

Introducing a rule engine was seen as a way to separate business decision logic from system logic, reducing maintenance costs.

Case Study: Store Information Validation

Before the Meituan‑Dianping merger, the store information entry point performed quality control through field validation rules. The simplified rule model includes three parts: branch conditions (using "==" and "<"), simple calculations (e.g., string length), and business‑custom calculations (e.g., reverse geocoding).

The original implementation used hard‑coded Java checks:

if (StringUtil.isBlank(fieldA) || StringUtil.isBlank(fieldB) || StringUtil.isBlank(fieldC) || StringUtil.isBlank(fieldD)) {
    return ResultDOFactory.createResultDO(Code.PARAM_ERROR, "Missing required store parameters");
}
if (fieldA.length() < 10) {
    return ResultDOFactory.createResultDO(Code.PARAM_ERROR, "Store name must be at least 10 characters");
}
if (!isConsistent(fieldB, fieldC, fieldD)) {
    return ResultDOFactory.createResultDO(Code.PARAM_ERROR, "Address, district, and coordinates are inconsistent");
}

Advantages

Highest development efficiency when rules are few and stable.

Good stability; syntax errors are caught at compile time.

Disadvantages

High iteration cost: any rule change requires a full development‑test‑deploy cycle.

Maintainability suffers as the number of rules grows.

Business analysts cannot modify rules themselves; developers must intervene.

Case Study: Store Audit Process

The flow control center selects audit nodes based on store source and brand. The rule model is a simple branch condition.

Initially, rules were hard‑coded; later the team evaluated Drools. Example Drools DSL:

rule "1.1"
    when
        poi : POI( source == 1 && brandType == 1 )
    then
        System.out.println( "1.1 matched" );
        poi.setPassedNodes(1);
end

rule "1.2"
    when
        poi : POI( source == 1 && brandType == 2 )
    then
        System.out.println( "1.2 matched" );
end

rule "2.1"
    when
        poi : POI( source == 2 && brandType == 1 )
    then
        System.out.println( "2.1 matched" );
        poi.setPassedNodes(2);
end

rule "2.2"
    when
        poi : POI( source == 2 && brandType == 2 )
    then
        System.out.println( "2.2 matched" );
        poi.setPassedNodes(3);
end

Drools Pros

Decouples strategy rules from execution logic, easing maintenance.

Drools Cons

Business analysts still need developers to maintain DSL code.

Scalability degrades as rule count grows.

Nested conditions require Cartesian‑product expansion, hurting maintainability.

The Drools approach was eventually abandoned.

Case Study: Performance Metric Calculation

Rapid iteration of performance rules is required; hard‑coded implementation demanded heavy developer effort.

In October 2016 a dedicated project built a performance‑metric configuration system, reducing product‑manager and developer workload by 70%.

The rule body processes structured data: it fetches data from multiple sources, aggregates via SQL‑like queries, and outputs results.

A custom rule‑engine solution was designed, with a view‑driven UI for analysts.

Advantages

Low configuration barrier; analysts can easily create rules.

Supports hot deployment.

Disadvantages

Limited to performance‑metric domain; hard to reuse elsewhere.

Summary of Case Findings

Hard‑coded solutions have high iteration cost.

Drools incurs high maintenance overhead and is unfriendly to non‑technical users.

Custom performance engine has limited expressiveness and poor extensibility.

Requirement Model

Rules are viewed as functions: y = f(x1, x2, …, xn). The model consists of three parts:

FACT objects – input facts from users.

Rules – LHS (conditions) and RHS (actions) built from patterns. Patterns can be custom methods, regular expressions, or structured queries.

Result objects – output values (primitive or custom types).

System Model

The system comprises three modules:

Knowledge base – provides configuration views and pattern factors, enabling low‑cost knowledge expansion.

Resource manager – handles versioning, dependency management, and rule storage.

Rule engine – includes a scheduler (optimizing throughput) and pattern executors (which may use Drools, Aviator, or ANTLR).

Maze Framework

The Maze framework consists of two engines: MazeGO (strategy) and MazeQL (structured data). MazeGO parses strategy patterns and delegates to SQLC for data queries; MazeQL parses data patterns and delegates to VectorC for vector calculations.

MazeGO Core Modules

Resource manager – version control, dependency handling.

Knowledge base – view‑driven rule configuration.

Engine – pre‑loads and pre‑compiles rule instances; listens for changes via ZooKeeper.

Traffic controller – routes traffic to different rule versions for gray releases.

Rule effect analysis – records execution paths and parameters for offline analysis.

Example client initialization:

// Initialize MazeGO client (usually at application start)
MazeGOReactor reactor = new MazeGOReactor();
reactor.setMazeIds(Arrays.asList(<mazeId>));
reactor.init();

// Execute a rule
reactor.go(<mazeId>, <fact>);

// Destroy client (usually at shutdown)
reactor.destroy();

MazeQL Core Modules

Configuration center – version management, data source binding, SQL rule definition, VectorC definition.

Engine – pre‑loads rule instances, pre‑parses them into runtime stacks.

Platform – executes rules either embedded (MySQL/Derby) for low‑latency workloads or on Spark for large‑scale offline processing.

Capability Model

Low configuration cost: analysts can configure rules via UI.

Hot deployment: version control enables gray releases.

Expression ability: supports most programming constructs, including custom methods, arithmetic, relational operations, and structured queries.

Execution efficiency: scheduler prioritizes throughput, no remote calls during execution, compiled or parsed code runs fast.

Integration cost: developers import a single MazeGO jar and use the client API; rule configuration is self‑service for analysts.

Conclusion

The article introduced several real‑world rule scenarios, evaluated three solution approaches (hard‑coding, Drools, custom performance engine), and presented the design of the Maze framework that addresses the identified shortcomings while providing a scalable, low‑cost rule configuration platform.

Thought Question

When a general‑purpose rule engine can express most business logic and its configuration cost is lower than direct development, where should we draw the line between using a rule engine and writing code, and must we still strictly adhere to principles like “isolating change” and “decoupling decision logic”?