Global system rate limit as safety net

Per-campaign and per-ISP limits are only as safe as their configuration — a misconfigured campaign with no maxPerHour and a per-ISP limit set too high can still dispatch thousands of messages per minute if there is no outer bound. A global system rate limit is the circuit breaker: regardless of what any campaign or ISP limiter is configured to allow, the system as a whole cannot exceed this ceiling. This single control prevents a configuration error, a bug in rate limit logic, or a runaway queue worker from causing catastrophic volume spikes that would require weeks of reputation recovery.

Implement the global rate limiter as the outermost layer all sends pass through, configurable via environment variable so it can be adjusted without deployment:

const GLOBAL_MAX_PER_MINUTE = parseInt(
  process.env.EMAIL_GLOBAL_MAX_PER_MINUTE ?? '500'
)

const systemRateLimiter = new Bottleneck({
  reservoir: GLOBAL_MAX_PER_MINUTE,
  reservoirRefreshAmount: GLOBAL_MAX_PER_MINUTE,
  reservoirRefreshInterval: 60_000,
})

// Every send in the system goes through this first
export async function scheduleEmail(job: EmailJob): Promise<void> {
  await systemRateLimiter.schedule(() => sendWithThrottle(job))
}

Set EMAIL_GLOBAL_MAX_PER_MINUTE in your environment configuration (not hardcoded) and document the rationale for the chosen value. Add a monitoring hook that logs when the reservoir drops below 20% of capacity, signaling the system is approaching the ceiling.