Requirements

Functional Requirements:

• Define rules as condition-action pairs, where each rule has a condition that evaluates against facts and an action that fires when the condition is true.
• Evaluate rules against a set of facts, where the rule engine accepts a collection of facts and evaluates each rule's condition against them.
• Support rule priority and conflict resolution to determine execution order when multiple rules match simultaneously.
• Group rules into rule sets for organized evaluation, where rule sets can be evaluated independently or chained.

Non-Functional Requirements:

• Thread Safety: When multiple rules fires simultaneously and tries to modify the same fact, we maintain thread acquiring a lock while processing, other threads must be in queue. Basically we can arrange this based on the rule priority, by using Priority Queue.
• Extensibility: Use Rule Interface that allows seamless experience on adding or updating rule's condition expressions and actions types.
• Performance: Use multiprocessing for evaluation and executions of multiple independent rules using vCPUs or multiple nodes in a distributed system. We can also use caching for storing evaluation results of a rule against facts so that we can avoid re-evaluation of the same rule against same fact collection.

Core Objects & Relationships

The main Components here should be

Classes:

1. Rule Engine: This will accept the a collection of facts to evaluate the given rules against them and iterates rules in priority order — each Rule decides independently whether its condition matches. All matching rules are collected for conflict resolution, then fired in priority order.
2. Rule: This is core unit of the Business Rule Engine System, this is mainly trigger the eval and execute actions.
3. Fact: This simply represent a fact object.
4. RuleSet: A named collection of Rules grouped for a specific purpose (e.g., "Pricing Rules"). Contains evaluation strategy (all matching vs. first match). Manages priority ordering of its rules.
5. Evaluation Context: This actually tracks the evaluation results for all the facts and also help identify the stale facts by any Rule engine instance even if they are running on separate thread. It can also help us identify the cyclic dependency of a rule.

Interfaces:

1. Condition: This allow client to define the evaluate given the Facts wrapped within evaluation context.
2. Action: Each Action implementation is self-contained — the Rule calls `action.execute(context)` without knowing what the action does. This makes adding new actions as simple as implementing a single-method interface.

• execute(context: EvaluationContext): void — performs an operation when a rule's condition is met
• Common implementations:
  • DiscountAction(order_total_field, percentage) — modifies fact values
  • NotificationAction(message, channel) — triggers external side effects (email, SMS, alert)
  • FlagOrderAction(flag_name) — tags facts for downstream processing
  • CompositeAction(actions) — chains multiple actions for one rule
• Important consideration: Actions can mutate facts, which may trigger forward chaining — re-evaluation of rules. `EvaluationContext` tracks modified_keys to support this safely.
• Side effects: Actions like NotificationAction call external systems. Consider making them async to avoid blocking the evaluation pipeline.

1. EvaluationStrategy: It determines how the engine processes rules within a RuleSet.

The above interfaces helps developer add any condition actions easily without touching core logic of the rule engine.

APIs & Class Members

For each class, define the attributes (data) it will hold and the methods (functions) that operate on the attributes. Ensure they align with the object's responsibilities and adhere to the principle of encapsulation. Write your code in the code editor below.

Deep Dive

Explain design tradeoffs you considered. Check and explain whether your design adheres to SOLID principles. Explain how your design can handle changes in scale and whether it would be easy to extend with new functionalities. Identify areas for future improvement...

Solid Principle Adherence

• Single Responsibility: Each classes above (e.g Rule engine) always delegated the task to the `Condition` class for eval and to the `Action` class for execute.
• Open/Close Principle: Each of the interfaces are open for extension but closed to the modification
• Liskov Substitution Principle: This is not directly applicable here because we are not using inheritance. Superclass should replaceable with Subclass
• Interface Segregation Principle: Client are not forced to implement abstract method that they don't use.
• Dependency Inversion Principle: High level module should not depend on low level module , both should depend on abstractions

Horizontal Scaling

• Multiple Rule Engine instances — each handles a subset of rules (shard by rule type or tenant)
• Evaluation Engine is stateless by design — easy to spin up more workers
• Facts come in → placed on a queue → workers pick up and evaluate

Isolated Evaluation Sessions

Each call to rule_engine.evaluate(rule_set_id, facts) creates a fresh EvaluationContext — this is your isolation boundary:

Why this works:

• No shared mutable state — each session has its own context tracking which rules fired, what facts changed, and what results were produced
• Facts are input copies — the engine operates on a snapshot. If external changes happen mid-evaluation, they're picked up on the next evaluation, not during
• Stateless workers — any worker can handle any request because nothing persists between sessions

Trade-off: If multiple sessions need to see the same fact changes (e.g., inventory deductions), you'd layer a shared cache (Redis) on top and have actions call into it explicitly — the evaluation session stays isolated, but side effects go to shared storage.

Potential Bottleneck

Our current design shows the Evaluation Engine passing results to the Execution Engine. If rules modify shared state (facts), We need coordination across instances — otherwise two workers might evaluate stale facts simultaneously.

Options

1. Partition by fact scope — each engine instance owns a partition of facts (e.g., rules for customer region A vs B)
2. Optimistic locking — workers evaluate against a fact version, retry if stale
3. Sequential processing per rule group — rules that touch the same facts run on the same worker
4. forward chaining — What happens when rule A fires, modifies fact X, and that change triggers re-evaluation of rule A itself? We need a termination strategy
   • Limit the number of re-evaluation passes
   • Mark rules as "already fired this cycle"
   • Detect cyclic dependencies

Rete Algorithm — For large rule sets at scale, evaluating every rule against every fact each time is O(rules × facts). The Rete algorithm pre-compiles conditions into a discrimination tree, so when a fact changes, only affected partial matches are re-evaluated — near O

Future Improvements:

1. DSL & Visual Rule Builder

A domain-specific language (DSL) could let business users write rules like:

A parser transforms this into CompositeCondition(AND, ThresholdCondition, ComparisonCondition) + DiscountAction. A visual rule builder with drag-and-drop condition/action blocks could generate the same AST — requiring no coding. The key design requirement: the Rule/Condition/Action interfaces must remain stable so new DSL constructs map to existing primitives.

2. Rule Versioning & A/B Testing

RuleSets should support versioned deployments:

• Each RuleSet edit creates a new immutable version (v1, v2, v3)
• Rules can target a specific version by ID: engine.evaluate("pricing:v2", facts)
• A/B testing: route X% of traffic to v2, Y% to v3, backed by metrics (approval rate, revenue impact)
• Implementation: RuleSetRegistry stores versioned snapshots, routing layer uses a hash of user_id for consistent assignment

3. Backward Chaining (Goal-Driven)

Forward chaining starts with facts and fires matching rules. Backward chaining starts with a goal and works backwards to find what facts would make it true:

This is powerful for diagnostic/validation scenarios — "why didn't this customer get a discount?" — and can be layered as an optional alternative to forward chaining via a BackwardChainingEngine implementing the same RuleEngine interface.