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 trying to modify the same fact , we should always maintain thread lock once one rule acquired the lock the other rules should be in the thread queue.
• Extensibility: We should maintain a Rule Interface where a Developer can register new rules which includes new condition type and action type.
• Performance : We should implement multi processing so that we can evaluate multiple rulesets simultaneously into vCpu node or we consider using totally different physical nodes or containers.
• Rule Store : We should have rule store where we save our Condition and Action Pairs and provide an independent API endpoint to manage the rules

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: This allows client to define the execute the action of a rule when condition met.

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

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