How do I throttle email sends so I don't get rate limited during spikes?

To avoid rate limits during traffic spikes, you want to smooth outbound email traffic rather than sending immediately at full burst speed.

Practical approaches

1. Put email jobs on a queue

Don’t send emails inline in your request path. Instead:

• enqueue an email job
• have background workers send them
• control worker concurrency and throughput

This gives you a central place to throttle.

---

2. Rate-limit at the worker

Apply limits like:

• max sends per second
• max sends per minute
• max concurrent SMTP/API requests
• per-domain limits if providers vary by recipient domain

Examples:

• 5 emails/sec overall
• 1 email/sec to the same provider/domain
• 10 concurrent sends total

A token-bucket or leaky-bucket limiter works well.

---

3. Add a retry strategy with backoff

If the provider returns a rate-limit response:

• retry with exponential backoff
• add jitter
• honor Retry-After if provided

Example pattern:

• wait 1s
• then 2s
• then 4s
• then 8s
• stop after a reasonable max retry count

---

4. Batch and coalesce where possible

If you’re sending many similar notifications:

• combine them into digests
• suppress duplicates
• delay non-urgent messages by a few minutes
• collapse “same user, same event” notifications

This reduces volume during spikes.

---

5. Use provider-specific limits

Many email services have documented limits for:

• sends per second
• daily quotas
• warm-up for new accounts/IPs
• per-domain throttling

Configure your throttles below those limits, not at them.

---

6. Separate urgent and non-urgent mail

Use different queues:

• high priority: password resets, OTPs
• normal: notifications
• low priority: digests, marketing

Then allocate bandwidth accordingly.

---

A simple design

A solid starting setup:

• Queue all outbound mail
• One or more workers
• Global limiter: e.g. 20/minute
• Per-domain limiter: e.g. 5/minute
• Retry on 429/421/4xx throttling with exponential backoff
• Dead-letter queue after repeated failures

---

If you’re using SMTP

Watch for SMTP responses like:

• 421 temporary failure
• 450 mailbox unavailable
• 451 local error
• 452 insufficient system storage / rate issues

Treat these as transient and back off.

---

If you’re using an email API

Look for:

• HTTP 429 Too Many Requests
• Retry-After header
• provider-specific rate-limit headers

---

Rule of thumb

For spikes, the safest combo is:

1. queue everything
2. limit send rate centrally
3. retry with backoff
4. prioritize critical mail
5. dedupe/coalesce where possible

If you want, I can show:

• a Redis token-bucket implementation
• a Node/Python/Go example
• or a queue-based architecture diagram for throttled email sending.