A behind-the-scenes look at how the service works, design decisions, and scalability considerations.

By @Meet Modi

TL;DR: An enterprise-grade email scheduling system designed to handle high-throughput campaigns. It uses an asynchronous worker architecture to decouple API ingestion from email delivery, ensuring strict rate limits and fault tolerance.

1. The Core Problem

In a standard web server, sending an email is a "blocking" operation. It takes 1–3 seconds to handshake with an SMTP server.

• The Naive Approach: If a user schedules 1,000 emails in a loop, the server hangs for ~30 minutes. If the server restarts, all pending emails are lost.
• My Solution: A Producer-Consumer architecture. The API (Producer) accepts the request instantly and pushes it to a persistent Queue. A separate Worker (Consumer) processes the emails in the background.

Here is how the system handles scale:

1. Decoupling Ingestion from Delivery Sending emails is slow. Accepting requests should be fast. Instead of blocking the API, requests are instantly offloaded to a persistent Redis queue (BullMQ). The API responds in sub-50ms, while background workers churn through the queue asynchronously.

2. Handling the "Noisy Neighbor" Problem If one user schedules 10k emails, they shouldn't block everyone else. I enforced strict tenant isolation using atomic Redis counters and a Token Bucket strategy. If a limit is hit, the system doesn't drop the data, it intelligently calculates the backoff and auto-reschedules the job for the next window.

3. Real-Time Feedback I implemented Server-Sent Events (SSE) to push "Sent" updates to the dashboard instantly without inefficient polling.

2. System Architecture

Key Components:

• Producer (Express API): Accepts CSV uploads, validates data, and creates "Pending" jobs in Postgres and Redis. Latency: <50ms.
• Message Queue (BullMQ): Acts as the buffer. It handles job delays (scheduling for the future) and retries (if SMTP fails).
• Worker (Node.js): A dedicated process that polls Redis. It handles concurrency (processing 5 jobs at once) and the heavy lifting of sending emails.
• Storage:
  • PostgreSQL: The "Source of Truth" for job history (Sent/Failed logs).
  • Redis: Used for the Queue and ephemeral Rate Limit counters.