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:

# Concurrent requests — each gets its own context
def handle_request(request):
    facts = Facts(request.data)          # fresh facts per session
    context = engine.evaluate("pricing", facts)  # isolated context
    return context.results

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

Partition by fact scope — each engine instance owns a partition of facts (e.g., rules for customer region A vs B)
Optimistic locking — workers evaluate against a fact version, retry if stale
Sequential processing per rule group — rules that touch the same facts run on the same worker
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:

IF order_total > 100 AND customer_tier == "gold"
THEN apply_discount(15%)

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:

Goal: customer_gets_discount(true)
→ Which rules conclude this? Rule(condition: tier == "gold", action: set discount)
→ So we need fact: tier == "gold"
→ Check if tier is in facts. If not, find rules that set it.

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.

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10