How to Build a Scalable Rule Engine for High‑Volume Business Logic

Introduction

In July 2016 Meituan Dianping entered the second half of its business lifecycle, requiring optimization of experience, efficiency, and cost across all stages. The CRM business of Meituan Waimai matured, with rule‑based requirements accounting for half of all demands, yet developers found rule development tedious, low‑tech, and exhausting. A rule engine was considered to separate business decision logic from system logic, reducing maintenance costs.

Case Studies

Several Meituan Dianping scenarios are reviewed to illustrate what rules are and their boundaries. Each scenario describes the current solution, its advantages, and drawbacks.

Store Information Validation

Scenario : The store information entry point acts as the first quality‑control gate, enforcing field validation rules.

The rule body consists of three parts: branch conditions (using == and <), simple calculation rules (e.g., string length), and business‑custom calculation rules (e.g., reverse geocoding).

Solution – Hard Coding

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 length must be at least 10 characters");
}
if (!isConsistent(fieldB, fieldC, fieldD)) {
    return ResultDOFactory.createResultDO(Code.PARAM_ERROR, "Store address, district, and coordinates are inconsistent");
}

Pros : Highest development efficiency when rules are few and stable; good stability because syntax errors are caught at compile time.

Cons : High iteration cost; poor maintainability with many rules; high barrier for business analysts who cannot see or modify rules themselves.

Store Review Process

Scenario : The process control center selects workflow nodes based on store attributes such as channel source and brand.

The rule body is a simple equality branch condition using fixed values and user‑provided attributes.

Solution – Drools (Adopted then Abandoned)

After research, the team adopted the open‑source Drools engine to configure node‑selection strategies.

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

Pros : Decouples strategy rules from execution logic, easing maintenance.

Cons : Business analysts still cannot configure rules independently because the DSL is a programming language; scalability suffers as rule count grows; nested conditions are hard to express; ultimately the Drools approach was discarded.

Performance Indicator Calculation

Scenario : Rapidly iterating performance‑metric rules to keep pace with Meituan Waimai’s fast growth, with monthly updates.

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

The rule body performs structured data processing: fetch data from sources, aggregate via SQL‑like queries plus minimal code, and output results.

Solution – Custom Business Rule Engine

The engine provides a low‑threshold configuration UI for analysts, supports hot‑deployment, but is tightly coupled to the performance‑business model, limiting reuse.

Exploring a New Design

The three previous solutions share common problems: high iteration cost for hard‑coding, high maintenance barrier for Drools, and limited expressiveness for the custom engine. To address the long‑standing need for efficient rule configuration, a virtual team was formed in February 2017 to design the Maze framework.

Requirement Model

Rules are treated as functions y = f(x1, x2, …, xn). The model defines FACT objects (input), rule conditions (LHS), actions (RHS), and result objects. Patterns (the smallest rule unit) support custom methods, regular expressions, and structured queries.

System Model

The system consists of three modules: Knowledge Base (provides configuration views and patterns), Resource Manager (handles versioning, dependency resolution), and the Rule Engine (executes rules). Additional components include a Scheduler, Pattern Executors, and a Flow Controller for traffic shaping.

Maze Framework

The Maze framework (Maze = maze) comprises two engines: MazeGO (strategy engine) and MazeQL (structured‑data engine). MazeGO translates structured‑data patterns to SQLC, while MazeQL translates strategy patterns to VectorC. This dual‑engine design enables both SQL‑style aggregation and per‑row vector calculations.

MazeGO

Core components: Resource Manager, Knowledge Base, MazeGO Engine, plus a Traffic Controller and Rule‑Effect Analyzer. The engine pre‑loads and pre‑compiles rule instances, supports versioned gray‑release, and records execution paths for analysis.

MazeQL

Core components: Configuration Center, MazeQL Engine, and Platform. It also pre‑loads, pre‑parses, and schedules rules. The platform can run embedded (low‑latency) or on Spark (large‑scale batch).

Maze Capability Model

The framework targets non‑technical users, offering hot‑deployment, version control, and expressive power comparable to code.

Rule Iteration Safety

Supports hot‑deployment with versioned gray‑release to increase confidence during rollout.

Rule Expressiveness

Provides near‑code‑level expressiveness. Example pseudo‑code demonstrates input FACT extraction, SQLC data fetching, user‑defined computation, conditional logic, and result return.

// Input N FACT objects
function(Fact[] facts) {
    String xx = facts[0].xx;
    List<Fact> moreFacts = connection.executeQuery("select * from xxx where xx like '%" + xx + "%'");
    UserDefinedClass userObj = userDefinedFuntion(facts, moreFacts);
    int compareResult = userObj.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;
}

Rule Execution Efficiency

Three aspects: scheduler prioritizes throughput, no remote‑call overhead during execution, and compiled/parsed rule code runs fast.

Rule Integration Cost

For Developers :

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

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

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

For Configurers : Business analysts can configure rules via a visual UI without writing code.

Conclusion

The article introduced several real‑world rule scenarios, evaluated multiple solutions, and detailed the design of the Maze framework, showcasing the complete thought process behind building a flexible, maintainable, and high‑performance rule engine.