Closed-Loop Throughput Tuning
Adjust delivery concurrency from smoothed per-destination outcomes rather than from static configuration — with ceilings a loop can never exceed.
Runtime state: The learning agent updates on every delivery outcome inside the running engine, clamped by configured ceilings.
- Business objective
- Deliver as fast as receiving infrastructure will actually accept, which is a moving number that no static configuration can express.
- Trigger
- Every delivery outcome during an active send.
- Inputs
- Per-message outcomes — accepted, deferred, permanently failed
- Existing smoothed metrics for the destination group
- Configured concurrency ceilings for the lane
- Destination classification from filter-sensitive routing
- Outputs
- A recommended concurrency per destination group
- Applied concurrency, always within ceilings
- Updated smoothed metrics
- Operator-visible throughput and deferral behavior
Why static limits fail
A per-provider rate limit in a configuration file is a guess about a number that moves. Receiving infrastructure throttles differently by time of day, by sender reputation, and by how hard you have just pushed it.
Set the limit low and every campaign takes longer than it needs to. Set it high and you buy deferrals, then blocks, which cost far more than the time saved. The limit is only correct at the moment it was written, and it is never revisited.
The workflow
Outcome to applied concurrency
A control loop, not a prediction. Every input is a measured outcome.
- External service
Delivery outcome received
Accepted, deferred with a retry time, or permanently failed.
- Automated software
Attribute to a destination group
Grouped by routing target, so behavior is learned per receiver rather than globally.
- Monitoring / feedback
Update smoothed metrics
Exponentially weighted averages, so recent behavior dominates without a single outcome causing a swing.
- Automated software
Compute recommended concurrency
Decision point: Acceptance improving and deferrals low — increase, slowly. Deferrals rising — decrease, immediately.
- Approval gate
Clamp to configured ceilings
Decision point: The recommendation is advisory. Lane ceilings and per-destination caps are hard limits the loop can never exceed.
- Automated software
Apply to the engine
Worker concurrency and connection pool behavior adjusted for that destination group.
- Automated software
Deliver at the new level
Producing the next set of outcomes, closing the loop.
- Human action
Operator observes
Live throughput and per-destination behavior on the dashboard. Ceilings are adjusted by a person, never by the loop.
- Human action
- Automated software
- External service
- Approval gate
- Monitoring / feedback
Decision points
- Increase, hold or decrease? Driven by smoothed acceptance and deferral rates.
- How fast to recover? Deliberately asymmetric — decrease quickly, increase slowly.
- Is the recommendation within ceilings? Clamped without exception.
- Should the ceiling itself change? Human decision, informed by observation.
Responsibilities
AI / LLM
- Explaining an unexpected throughput pattern to an operator during diagnosis — after the fact, never in the loop.
Deterministic
- Outcome attribution to destination groups.
- Smoothed metric calculation.
- The concurrency recommendation.
- Ceiling clamping.
- Applying concurrency to engine workers.
- Every number shown to the operator.
Human approval points
- Setting the ceilings. The loop operates inside them and can never raise them.
- Changing the recovery curve or smoothing parameters.
- Intervening when the loop stabilizes somewhere unexpected, which is a signal about reputation or content rather than about tuning.
Failure handling
| Failure | Response |
|---|---|
| Recommendation exceeds the ceiling | Clamped. The ceiling is the contract; the recommendation is advisory. |
| Deferrals spike | Concurrency reduced immediately. Decrease is fast by design. |
| Metrics unavailable for a new destination | Start at the conservative default for its class rather than at the lane default. |
| Loop oscillates | Smoothing parameters are the fix; oscillation means the average is too responsive. |
| Sustained low throughput at ceiling | Escalate to a person — the constraint is reputation or content, not concurrency. |
| Blocking response | Delivery to that group stops and the incident is escalated. The loop does not retry through a block. |
Monitoring
Applied versus recommended concurrency, acceptance and deferral rates per destination group, time at ceiling, backoff frequency, and oscillation amplitude. Time spent at the ceiling is the signal that a human should reconsider the ceiling.
Business value
Static rate limits are either too conservative, so campaigns take longer than they need to, or too aggressive, so deferrals and blocks cost more than the time saved. This removes the guess.
Related projects
- giMTA — High-Volume Email Delivery EngineStatus: Production
A purpose-built Rust mail server for high-volume sending — it resumes after an interruption without re-sending a single message, and learns each provider's rate limits instead of guessing them.
- MailerClub — Email Marketing PlatformStatus: Production
A Go platform that takes a campaign from recipient list to delivered mail — unsubscribes and bounces enforced on every send, automatic delivery protection, and full event reporting.
Related workflows
- Filter-Sensitive Delivery Routing
Detect when a destination sits behind protective filtering infrastructure and apply the most conservative delivery profile — treating its signals as authoritative rather than as an obstacle.
- DNS Pre-warming Before Sending
Resolve every recipient domain before the first message leaves, and refuse to start when too few resolve — turning a confusing class of deferral into an immediate, legible failure.
- Campaign Creation to Delivery
From an operator composing a campaign to messages accepted by receiving providers, through a single mandatory suppression gate and a fail-closed readiness barrier.