Smart Sending Infrastructure & Sharding 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.
Campaign Triggered
A campaign starts and requests a batch of jobs from the database.
Queue Injection
Recipient jobs are pushed to BullMQ with individual randomized delay timestamps (jitter).
Account Rotation
Workers query Redis for the next active sending account, skipping accounts in cool-down.
Relay Connection
Credentials are decrypted in-memory, and Nodemailer establishes an encrypted TLS session to relay the email.
Feedback Loop
If the provider reports throttling (421/429), the account is flagged in Redis to cool down for 60 minutes.
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 smart sending infrastructure & sharding behaves.
Answers about the execution flow, failure handling and limits of this module.
What is email sharding and why does it improve deliverability?
Email sharding splits one campaign's volume across several sending accounts and domains instead of pushing everything through a single mailbox. Because spam filters key on volume-per-sender in a short window, spreading 5,000 messages across 25 mailboxes means each one sends 200 rather than 5,000 - well inside normal business behaviour.
Which email providers can I relay through?
Google Workspace, Microsoft 365, and any custom SMTP server. Connections enforce STARTTLS on port 587, and connection pooling avoids repeating the handshake for every message.
How does the round-robin rotation decide which account sends next?
An atomic Redis counter advances a pointer through the pool of ready accounts, so concurrent workers can never pick the same account twice. Accounts that are in cool-down, unauthorised or rate-limited are skipped automatically.
How fast can each account send?
A random 25 to 45 second delay is applied between messages, which works out at roughly 80 to 144 emails per hour per account. The delay is calculated when the job is queued and baked into the scheduled dispatch, so workers never sit idle waiting.
What happens if a sending account starts failing?
An SMTP 421 or 429 response puts that account into a 60-minute cool-down, recorded as an expiring Redis key so it restores itself automatically. The remaining accounts keep sending. If every account goes offline, the campaign pauses and alerts you rather than burning through the list with failures.
When do daily sending limits reset?
At 00:00 UTC, via a scheduled job. That matches how Google and Microsoft account for daily quotas, so your counters and theirs stay aligned.