Rule engine design

Overview

A rule engine evaluates business rules (conditions and actions) against facts, separating frequently changing policy from application code. Examples: discounts (if cart > 100 and member, 10% off), fraud checks (if amount > 5,000 and new device, flag), eligibility, routing, and pricing. Rules have a condition, an action or outcome, and often a priority.

The LLD centers on a Rule interface (matches(facts), apply(facts)), composable conditions (AND, OR, NOT via the Composite or Specification pattern), a RuleEngine that evaluates rules in priority order with a strategy (first match, all matches), and optionally loading rules from configuration so non-engineers can change them.

When to use it

• Business rules change often and independently of code.
• Many combinable conditions (discounts, eligibility, fraud).
• Interview prompt: 'Design a discount or rule engine'.

Where it shows up in interviews

Where it is used in real software

Key terms

Fact

Input data the rules evaluate (cart, user, transaction).

Condition / predicate

Boolean test over facts.

Action / outcome

What happens when a rule matches.

Specification pattern

Composable predicates with and/or/not.

Conflict resolution

Priority, first match, or combine all.

How it works, step by step

1. 1
   Define facts

   A typed context object.

2. 2
   Define conditions

   Small predicates, composable.

3. 3
   Define rules

   Condition + outcome + priority.

4. 4
   Choose evaluation strategy

   First match vs all matches; stackability rules.

5. 5
   Externalize configuration

   Load rules from JSON or a DSL; validate on load.

Discount rules

Cart subtotal 150, member = true, coupon = none, strategy: best single discount

Changing the strategy to 'stack all' would give 25; the rules themselves stay the same.

Implementation

1type Facts = { subtotal: number; member: boolean; coupon?: string; itemCount: number };2 3// Specification pattern: composable conditions4type Condition = (f: Facts) => boolean;5const and = (...cs: Condition[]): Condition => (f) => cs.every((c) => c(f));6const or = (...cs: Condition[]): Condition => (f) => cs.some((c) => c(f));7const not = (c: Condition): Condition => (f) => !c(f);8 9type Rule = { name: string; priority: number; when: Condition; discount: (f: Facts) => number };10 11interface Strategy { combine(matches: { rule: Rule; amount: number }[]): number }12const bestSingle: Strategy = { combine: (m) => Math.max(0, ...m.map((x) => x.amount)) };13const stackAll: Strategy = { combine: (m) => m.reduce((s, x) => s + x.amount, 0) };14 15class RuleEngine {16  constructor(private rules: Rule[], private strategy: Strategy) {}17  evaluate(facts: Facts) {18    const matches = [...this.rules]19      .sort((a, b) => b.priority - a.priority)20      .filter((r) => r.when(facts))21      .map((r) => ({ rule: r, amount: r.discount(facts) }));22    return { discount: Math.min(facts.subtotal, this.strategy.combine(matches)), applied: matches.map((m) => m.rule.name) };23  }24}25 26const rules: Rule[] = [27  { name: "member-10pct", priority: 2, when: (f) => f.member, discount: (f) => f.subtotal * 0.1 },28  { name: "big-cart", priority: 1, when: and((f) => f.subtotal >= 100, not((f) => f.coupon === "SAVE20")), discount: () => 10 },29  { name: "save20", priority: 3, when: or((f) => f.coupon === "SAVE20"), discount: () => 20 },30];31 32new RuleEngine(rules, bestSingle).evaluate({ subtotal: 150, member: true, itemCount: 3 }); // { discount: 15, ... }

Complexity and performance

Trade-offs

Variants and related techniques

Common mistakes

• Rules with hidden side effects.

  Fix: Keep conditions pure; perform actions after evaluation.

• Undefined conflict resolution.

  Fix: Specify priority and combine strategy explicitly.

• No audit of fired rules.

  Fix: Return and log which rules matched for explainability.

Interview questions

Practice problems