A worker pool of 50 that sends as fast as it can will look great in a load test and then collapse in production when the provider starts answering 429 with a Retry-After header.
Two limits, one queue
There is the limit the provider documents and the limit it enforces, and they are not the same number. The documented one is usually per second across the whole account; the enforced one can be per recipient domain, per sending IP, or per template category. A shared token bucket at the worker is the simplest thing that respects the documented number, and honouring Retry-After covers the rest.
Retry-After is a promise
A 429 with Retry-After: 30 means do not send for thirty seconds. Treating it as a normal transient error and retrying in one second is how a temporary throttle becomes a suspension. Pause the whole shard, not the single message.
Measure the thing you are limited on
If the provider limits per domain, your dashboard should show per-domain send rate and per-domain error rate. An aggregate 'emails per minute' graph hides the one domain that is being throttled, which is exactly the number you need when a customer says their verification emails are slow.
The cheap safeguard
Give every send path a deadline. If a message cannot be accepted within the deadline, fail it explicitly and surface an error instead of letting it rot in the queue where nobody can see it. A visible failure is a support ticket; an invisible one is churn.
Volanea exposes the provider's rate-limit headers and the per-domain error rate next to the send log, so throttling is visible before a customer notices.
Top comments (0)