BACK TO INSIGHTS
TECH: Architecture & SystemsAPR 28, 20268 MIN READBY Anuj Bansal

Central Calculator Engines: Scaling MERN for 270+ Client Sites

Exploring how consolidating distributed web calculator apps under a single unified node backend engine decreased client compile durations and reduced codebase maintenance complexity.

SHARE THIS ARTICLE:
Architecture & Systems
Client AClient BN SitesCENTRALENGINEmath.js rules<28ms RedisSINGLE DB
💡Key Takeaways & Executive Summary
  • Duplicating complex calculation logic across hundreds of frontend repositories creates maintenance paralysis and logic discrepancies.
  • Centralizing mathematical formulas into a versioned AST (Abstract Syntax Tree) engine ensures instantaneous policy propagation.
  • Storing formula rules declaratively in MongoDB allows non-technical administrators to adjust tax rates without redeploying code.
  • In-memory Redis caching slashes calculation response times to sub-40ms under heavy concurrent traffic.

When managing a portfolio of over 270 client web applications in the financial and tax sector, maintaining duplicated logic across repositories creates severe operational bottlenecks.

Originally, financial calculators — mortgage estimations, tax brackets, and compounding projections — were implemented directly inside individual React frontends. When regulatory policies changed, updating those calculations required modifying, testing, and deploying hundreds of separate repositories.

Centralized Calculation Microservice Architecture

We extracted the mathematical models into a centralized Node.js calculation engine:

bash
┌─────────────────────────────────────────────────────────────┐
│ 270+ Client Applications (Next.js / React)                  │
└──────────────────────────────┬──────────────────────────────┘
                               │ HTTP POST (Sub-40ms)
                               ▼
┌─────────────────────────────────────────────────────────────┐
│ Central Calculator Engine (Node.js / Express Cluster)       │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ AST Formula Evaluator (math.js / Sandbox Engine)        │ │
│ └─────────────────────────────────────────────────────────┘ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Redis In-Memory Cache (94% Hit Rate for Repeated Calcs) │ │
│ └─────────────────────────────────────────────────────────┘ │
└──────────────────────────────┬──────────────────────────────┘
                               │ Dynamic Rules & Parameters
                               ▼
┌─────────────────────────────────────────────────────────────┐
│ MongoDB Database (Declarative Formula Schemas & SemVer)     │
└─────────────────────────────────────────────────────────────┘

Declarative Formula Schema in MongoDB

Formulas are stored as versioned algebraic expressions with strict boundary constraints:

typescript
interface ICalculationRule {
  ruleCode: string;          // e.g. "SIP_COMPOUND_V2"
  version: string;           // "2.1.0"
  formulaExpression: string; // "P * (((1 + i)^n - 1) / i) * (1 + i)"
  parameters: {
    name: string;
    type: 'number' | 'percentage';
    min: number;
    max: number;
    defaultValue: number;
  }[];
  active: boolean;
}

In-Memory Caching with Redis

Because common financial queries frequently share standard parameter inputs, calculations are cached using deterministic input serialization:

typescript
export async function evaluateCalculation(ruleCode: string, inputs: Record<string, number>) {
  const cacheKey = `calc:${ruleCode}:${JSON.stringify(inputs)}`;
  const cachedResult = await redisClient.get(cacheKey);
  
  if (cachedResult) {
    return JSON.parse(cachedResult);
  }

const rule = await RuleModel.findOne({ ruleCode, active: true }).lean(); if (!rule) throw new Error('Invalid calculation rule');

const result = mathEngine.evaluate(rule.formulaExpression, inputs); await redisClient.setex(cacheKey, 3600, JSON.stringify(result)); return result; } ```

Results & Impact

  • Maintenance Effort Reduced by 90%: Updating a financial calculation is now a single database record update that takes effect across 270+ client sites without redeploying code.
  • Client Build Times Dropped by 50%: Removing mathematical dependencies reduced client-side bundle sizes and halved CI/CD build durations.
  • 100% Logic Consistency: Centralized execution eliminated calculation discrepancies and rounding variations across client portals.
AB
ABOUT THE AUTHOR

Anuj Bansal

Anuj Bansal is a freelance full stack developer based in Indore, India specializing in scalable Next.js architectures, React web applications, Node.js backends, and high-performance server infrastructure. Looking to build a production-ready product? Hire Anuj for your next web application or SaaS platform.

🚀READY FOR PRODUCTION

Planning to Build a Production-Ready Web Application?

From system architecture and Next.js engineering to database optimization and technical SEO — let’s build a fast, scalable web product tailored to your business goals.

Available for New Projects Free 30-Min Architecture Discovery💬 Direct Engineering Access
Current: Centralized Calculation Microservice Architecture

Get engineering notes in your inbox.

Real-world lessons, system design deep-dives, and production stories — delivered weekly.