Every ESP plan has hard sending limits — SES sandbox defaults to 1 send per second and 200 per day; SendGrid's free tier caps at 100 sends per second. Exceeding these limits produces 429 errors that fail jobs and degrade IP reputation if retried without backoff. CWE-770 (allocation without limits) applies when queue concurrency is uncapped relative to the ESP tier. The Deliverability Engineering Audit's IP reputation category depends on sends staying within known limits — this check verifies that those limits are actually documented and enforced in code, not just hoped to be safe.
High because sending above ESP tier limits produces throttling errors that increase bounce rate, consume retry budget, and can trigger account suspension on plans with anti-abuse enforcement.
Document ESP limits and wire them to the rate limiter configuration in a dedicated file (e.g., src/config/email-limits.ts):
// src/config/email-limits.ts
export const ESP_LIMITS = {
sendgrid: { perSecond: 100, perDay: 1_000_000 },
ses: { perSecond: 14, perDay: 50_000 } // SES sandbox defaults
} as const
// BullMQ rate limiter:
const limiter = { max: 100, duration: 1000 } // 100/second
Include the source plan tier and date in a comment — limits change when plans change. The queue limiter value must not exceed the documented per-second limit for the configured ESP.
ID: operational-resilience-email.capacity-scaling.volume-limits-documented
Severity: high
What to look for: Enumerate all configured ESPs and for each, count the number of documented rate limits (per-second, per-day, per-month, per-IP warm-up cap). List all ESP limit values found in code comments, constants files, README, or rate limiter configuration. Sending blind to limits is a common cause of deliverability collapse in the Deliverability Engineering Audit's IP reputation category.
Pass criteria: Sending limits for each configured ESP are documented in the codebase or adjacent documentation with at least 2 limit values (e.g., per-second and per-day). The queue rate limiter configuration is set at or below these limits. Before evaluating, quote the exact rate limiter values from the code or config.
Fail criteria: No documentation of ESP sending limits exists. The queue worker fires at full capacity with no configured rate ceiling. Or limits are documented but the rate limiter exceeds them.
Skip (N/A) when: The project sends no email — confirmed by the absence of any ESP SDK in package.json.
Detail on fail: "No ESP volume limits documented — queue concurrency is uncapped relative to ESP tier limits" or "SendGrid rate limit is 100/second on the current plan but the queue limiter allows 500/minute — 3x over limit"
Remediation: Document limits and configure the rate limiter accordingly in a config file (e.g., src/config/email-limits.ts):
// src/config/email-limits.ts
export const ESP_LIMITS = {
sendgrid: { perSecond: 100, perDay: 1_000_000 },
ses: { perSecond: 14, perDay: 50_000 } // SES sandbox defaults
} as const
// BullMQ rate limiter:
const limiter = { max: 100, duration: 1000 } // 100/second
Include the source plan tier and date in a comment so limits can be rechecked when the plan changes.