RuleFlow — Dynamic Rule Engine in Node.js

Problem Statement

Most applications hardcode business rules deep inside API handlers — if/elif/else chains that grow over time. Every small rule change requires a code change, PR review, test cycle, and deployment. For fast-moving businesses, this is a bottleneck.

I wanted to demonstrate that business logic can be configuration, not code — editable JSON rules that a non-engineer can modify without touching the application.

Demo

The demo implements an Airline Loyalty Program where tier upgrades and discounts are driven entirely by JSON rules:

Passengers earn tier status based on miles flown and spend
Discount percentages change based on tier
Upgrade thresholds are configurable without code changes
Rules can be added, modified, or removed at runtime

Architecture

Loading diagram...

Each rule is a JSON document with:

Conditions — field, operator, threshold
Actions — what to do when conditions match
Priority — execution order when multiple rules apply

The engine loads rules at startup, evaluates them in priority order against input data, and returns the first matching action. Rules can be hot-reloaded without restarting the server.

Tech Stack

Node.js / Express — API server and rule evaluation runtime
JSON — Rule definitions stored as configuration files
Drools-inspired pattern — condition-action pairs with priority ordering

Lessons Learned

JSON rules cover 90% of business logic needs. Simple field-operator-value conditions handle most real-world cases. Only build a DSL when JSON genuinely can't express the logic.
Priority ordering is essential. Without explicit priority, rule evaluation order depends on file system order or insertion order — neither is reliable. Always make priority explicit.
Validation at load time, not evaluation time. Validate rule schemas when rules are loaded, not when they're evaluated. A malformed rule should prevent startup, not cause a runtime error on the 1000th request.
This pattern scales to production. The same architecture — config-driven rules with an evaluator pipeline — powers credit decisioning, fraud detection, and pricing engines at scale. The airline demo is simple, but the pattern is production-proven.

Problem Statement

I wanted to demonstrate that business logic can be configuration, not code — editable JSON rules that a non-engineer can modify without touching the application.

Demo

The demo implements an Airline Loyalty Program where tier upgrades and discounts are driven entirely by JSON rules:

Passengers earn tier status based on miles flown and spend

Discount percentages change based on tier

Upgrade thresholds are configurable without code changes

Rules can be added, modified, or removed at runtime

Architecture

Loading diagram...

Each rule is a JSON document with:

Conditions — field, operator, threshold

Actions — what to do when conditions match

Priority — execution order when multiple rules apply

The engine loads rules at startup, evaluates them in priority order against input data, and returns the first matching action. Rules can be hot-reloaded without restarting the server.

Lessons Learned

JSON rules cover 90% of business logic needs. Simple field-operator-value conditions handle most real-world cases. Only build a DSL when JSON genuinely can't express the logic.

Priority ordering is essential. Without explicit priority, rule evaluation order depends on file system order or insertion order — neither is reliable. Always make priority explicit.

Validation at load time, not evaluation time. Validate rule schemas when rules are loaded, not when they're evaluated. A malformed rule should prevent startup, not cause a runtime error on the 1000th request.

This pattern scales to production. The same architecture — config-driven rules with an evaluator pipeline — powers credit decisioning, fraud detection, and pricing engines at scale. The airline demo is simple, but the pattern is production-proven.