How HubNest Works

Every notification goes through five main stages: Client Trigger → Rule + Workflow Evaluation → Kafka Queue → Provider Routing → Delivery & Commit.

When an event arrives, two evaluation engines run simultaneously:

• Rule Engine: Evaluates all active Rules against the event payload. A Rule has a condition (e.g. amount > 5000) and an action (channel + template). If condition matches, the notification is dispatched immediately.
• Workflow Engine: Evaluates all active Workflows. Those whose TRIGGER node eventName matches the incoming event are executed as a DAG run with nodes: TRIGGER → CONDITION → SEND_ACTION → WAIT → UPDATE_FIELD → END.
• Both can fire on the same event simultaneously — Rule dispatch and multiple Workflow runs are independent.
• Event response includes ruleMatched (boolean), ruleNotificationStatus ("sent"/"error"), and workflowsTriggeredCount (number).

HubNest dynamically scores every connected provider based on live delivery success rates and response latency. If your primary AWS SES fails or rate-limits, traffic automatically redirects to your secondary SendGrid provider in under 150ms. Priority is set per provider (1 = highest priority).

To prevent over-sending and budget overruns, HubNest uses a 3-step wallet transaction model for every notification:

• Reserve: Before dispatching, the provider cost (e.g. ₹0.20 per SMS, ₹0.01 per email) is reserved from wallet balance.
• Commit: On carrier delivery success, the reserved amount is permanently debited from the wallet.
• Release: If delivery fails on all retry attempts, the reserved amount is returned to wallet balance.