Back to How it Works Index
Technical Deep-Dive

System Alerts & Transactional Routing Flow

Understand the core mechanics, queues, and logic routines running on our servers when processing this module.

System Execution Pipeline

Below is the step-by-step sequence of events executed by our background workers.

1

Event Triggered

An account gets blocked by an SMTP error or a campaign finishes.

2

Database Log

The system logs the notification in the database with status UNREAD.

3

WebSocket Push

The Socket.io server pushes the alert payload to active user sessions.

4

Transactional Fallback

For offline notifications, the system sends an email alert via Postmark/SendGrid.

Developer & Architect Notes

Technical Architecture

This module operates as a stateless service hosted across horizontally scalable server nodes. Distributed state coordinates through highly optimized Redis transactions to ensure consistency without deadlocks.

Notification ChannelsWebSocket + In-App UI
Transactional SMTPPostmark / SendGrid Relay

Edge Fail-Safe Rules

Critical protocols (like connection failure retries, cool-down timers, and data limits) are verified before outbound dispatches. Failures degrade gracefully, prioritizing list health and preventing blacklisting.

Data PersistenceMongoDB Notifications Collection
Latency TargetSub-second delivery of critical notifications