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.
Event Triggered
An account gets blocked by an SMTP error or a campaign finishes.
Database Log
The system logs the notification in the database with status UNREAD.
WebSocket Push
The Socket.io server pushes the alert payload to active user sessions.
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.
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.
How system alerts & transactional routing behaves.
Answers about the execution flow, failure handling and limits of this module.
How am I told when something goes wrong with a campaign?
In-app alerts arrive over a WebSocket connection as events happen - an account entering cool-down, a campaign pausing because every account went offline, or a quota being reached - so you find out while you can still act on it.
Are system emails sent through my own sending accounts?
No. Transactional messages such as password resets and alerts go through a dedicated gateway kept entirely separate from your marketing sending accounts, so platform mail never consumes your sending quota or affects your domain reputation.