Design and Implementation of the Maze Rule Engine for Efficient Business Logic

Introduction

In July 2016 Meituan‑Dianping entered the "second half" of its business, requiring optimization of experience, efficiency, and cost across all stages. The technical team needed a way to adapt to this change, especially for the CRM business where rule‑based requirements dominate.

The article explores how a rule engine can separate business decision logic from system logic, reducing maintenance cost and improving developer productivity.

Case Studies

Store Information Validation

The original solution used hard‑coded validation logic, illustrated by the following pseudo‑code:

if (StringUtil.isBlank(fieldA) || StringUtil.isBlank(fieldB) || StringUtil.isBlank(fieldC) || StringUtil.isBlank(fieldD)) {
    return ResultDOFactory.createResultDO(Code.PARAM_ERROR, "门店参数缺少必填项");
}
if (fieldA.length() < 10) {
    return ResultDOFactory.createResultDO(Code.PARAM_ERROR, "门店名称长度不能少于10个字符");
}
if (!isConsistent(fieldB, fieldC, fieldD)) {
    return ResultDOFactory.createResultDO(Code.PARAM_ERROR, "门店xxx地址、行政区和经纬度不一致");
}

Advantages: fast development when rules are few and stable. Disadvantages: high iteration cost, poor maintainability, and non‑technical analysts cannot modify rules.

Store Audit Process

The team tried Drools, an open‑source rule engine. A sample Drools DSL is shown below:

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 decoupled strategy rules from execution logic, but it still required developers to maintain DSL, and scalability suffered as rule size grew.

Performance Indicator Calculation

The performance‑metric rules were also hard‑coded, leading to massive monthly development effort. A custom rule‑engine system was built, providing a low‑threshold configuration UI and hot‑deployment capabilities.

Design of the Maze Framework

Based on the analysis, the team created the Maze framework, consisting of two engines: MazeGO (policy engine) and MazeQL (structured‑data engine). MazeGO parses strategy rules and delegates data‑intensive parts to MazeQL; MazeQL handles SQL‑like queries and vector calculations.

The overall architecture includes a Knowledge Base, Resource Manager, Scheduler, and Execution Modules. Key components:

Knowledge Base – stores configurable views and atomic patterns, enabling non‑technical users to assemble rules.

Resource Manager – handles versioning, dependency resolution, and rule lifecycle.

Scheduler – optimizes throughput or latency based on resource constraints.

Pattern Executors – can be backed by Drools, Aviator, ANTLR, or custom implementations.

MazeGO pre‑loads and pre‑compiles rule instances, monitors changes via ZooKeeper, and supports traffic control for gray releases. MazeQL provides SQLC (structured query) and VectorC (vector computation) capabilities, running either embedded (MySQL/Derby) or on Spark for large‑scale offline processing.

Capability Model

The framework offers:

Rule iteration safety through hot‑deployment and versioned gray‑release.

Rich expression power covering most programming constructs (shown in pseudo‑code below).

High execution efficiency via pre‑compiled code, local caching, and no remote call overhead.

Low integration cost for developers (simple JAR import and client API) and self‑service configuration for analysts.

// Example of a Maze rule function
function(Fact[] facts) {
    String xx = facts[0].xx;
    List<Fact> moreFacts = connection.executeQuery("select * from xxx where xx like '%" + xx + "%'");
    UserDefinedClass obj = userDefinedFuntion(facts, moreFacts);
    int compareResult = obj.getFieldXX().compare(XX);
    UserDefinedResultClass result = new UserDefinedResultClass();
    if (compareResult == 0) {
        result.setCompareResult(Boolean.FALSE);
    } else if (compareResult > 0) {
        result.setCompareResult(Boolean.FALSE);
    } else {
        result.setCompareResult(Boolean.TRUE);
    }
    return result;
}

Integration Example

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

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

// Destroy client on shutdown
reactor.destroy();

Conclusion

The article presented several real‑world rule scenarios, evaluated hard‑coding, Drools, and a custom performance engine, and finally introduced the Maze framework that addresses iteration cost, maintainability, and extensibility for complex business rules.

Author Bio

Zhang Ning, Technical Expert at Meituan‑Dianping, focusing on CRM efficiency and agent‑related services.