Building a Dynamic Business Logic Engine

Introduction

In the insurance and fintech sectors, “Time to Market” is the ultimate competitive advantage. However, traditional development cycles often slow this down. Every new product variation or rule change usually requires a ticket, a developer, code changes, testing, and deployment.

I recently tackled this problem by building a Dynamic Product Configurator Engine. The goal? Enable the business team to launch new insurance products and modify workflows immediately, without engineering intervention.

The Core Problem: Hardcoded Logic

The legacy system had business rules scattered throughout if/else statements in the code:

• If age > 60 and plan is “Gold”, add 10% premium.
• If region is “Coastal”, require flood insurance document.

Every time the business wanted to change “60” to “65”, we had to deploy code.

The Solution: Data-Driven Architecture

I shifted the paradigm from “Logic in Code” to “Logic in Database”. I designed a backend engine capable of interpreting JSON-based rule sets stored in the database.

1. The Dynamic Flow Structure

I defined products not as classes, but as a graph of nodes stored in MongoDB. Each node represented a step in the user journey (e.g., “Ask for Age”, “Select Coverage”).

graph TD
    subgraph "Product Configuration (MongoDB)"
        Config["Product JSON Config"]
    end
    
    subgraph "Dynamic Flow Nodes"
        N1["Node 1: Ask Age"]
        N2["Node 2: Select Plan"]
        N3["Node 3: Coverage Amount"]
        N4["Node 4: Calculate Price"]
    end
    
    Config --> N1
    N1 -->|"age > 60"| N2
    N1 -->|"age <= 60"| N3
    N2 --> N4
    N3 --> N4
    
    N4 --> UI["Rendered UI"]
    
    style Config fill:#ffa94d,stroke:#d9480f
    style N1 fill:#74c0fc,stroke:#1c7ed6
    style N2 fill:#74c0fc,stroke:#1c7ed6
    style N3 fill:#74c0fc,stroke:#1c7ed6
    style N4 fill:#51cf66,stroke:#2f9e44
    style UI fill:#ff6b6b,stroke:#c92a2a,color:#fff

2. The Rule Evaluator

At the heart of the backend was the Evaluator. We used a standardized JSON-logic format to define rules.

Example Rule stored in DB:

{
  "if": [
    { ">": [{ "var": "user.age" }, 60] },
    "high_risk",
    "standard_risk"
  ]
}

The backend FlowService would fetch the current configuration, inject the user’s context (state), and recursively evaluate these rules to determine:

1. What question to ask next?
2. Is the user eligible?
3. What is the calculated price?

sequenceDiagram
    participant U as User
    participant API as FlowService API
    participant DB as MongoDB
    participant Eval as Rule Evaluator
    
    U->>API: Request next step
    API->>DB: Fetch product config
    DB-->>API: Return JSON rules
    API->>Eval: Evaluate rules with user context
    Eval->>Eval: Process conditions
    Eval-->>API: Next node + eligibility
    API-->>U: Render question/result
    
    Note over Eval: Evaluates: {">": [{"var": "user.age"}, 60]}

3. Hot-Swapping Products

Because the “code” was essentially data, we could version these configurations.

• Version 1 is live.
• Business team works on Version 2 in a draft state via a CMS (Strapi).
• Once approved, Version 2 is published instantly.

The backend simply loaded the new JSON definition for the next request. Zero downtime. Zero deployments.

Challenges & Security

Allowing dynamic logic introduces risks. I had to implement strict schema validation and “Sanity Checks” to ensure a configuration couldn’t create an infinite loop or reference non-existent variables. I utilized extensive unit testing on the Evaluator itself to guarantee it strictly adhered to the logic standards.

Conclusion

By abstracting business logic into data, I transformed the backend from a bottleneck into an enabler. This architecture reduced the time required to launch a new product variation from weeks to hours.