Can you handle our volume?

Large audiences are a storage problem. Sending them safely is a different problem.

Every serious sender asks whether a platform can handle the list, the campaign, and the provider rate without losing control of billing or deliverability. The honest answer is not one throughput number. Import scale, commercial entitlement, sender reputation, live safety, and provider throughput are separate constraints.

Nitrosend keeps them separate in the architecture and joins them in one delivery decision. That makes the system fast where it should be fast and conservative where evidence is still thin.

Moving a large audience

A large CSV uploads directly to object storage. A single indexing pass records bounded byte ranges, then workers read independent chunks and write contacts, channels, custom fields, and memberships with set-based database operations. The API process never buffers the whole file and the import path never performs one ORM save per row.

large CSV
   |  signed upload; bytes do not cross the API process
   v
byte-range index
   |  one pass, bounded work units
   v
parallel batches
   |  bulk contacts, channels, fields and memberships
   v
audience available
   |  no automatic paid validation; no sender trust granted
   v
explicit review / validation / send operations

The boundary matters: importing five million rows proves that the database can hold five million rows. It does not prove consent, make the sender reputable, or authorize a five-million-recipient campaign. The import never starts paid validation, and validation itself never grants marketing consent or sending headroom.

Capacity belongs to the exact sender

Every exact email sender has independent capacity evidence. A Nitrosend brand-subdomain sender and a customer-owned domain under the same brand do not share reputation. Neither can borrow evidence from another brand, another provider route, or a future sender apex.

Capacity begins at a bounded floor and grows only from mature, clean volume that Nitrosend actually dispatched for that identity. Evidence waits at least 72 hours for feedback. The next capacity is at most twice the best representative clean day in the trailing 30 days, bounded by the sender's ceiling. A clean day currently requires at least 50 accepted recipients, no more than 1.5% hard bounces, and no more than 0.08% complaints.

Commercial plan capacity remains separate:

Included volume is not immediate dispatch permission. The binding result is the lowest applicable commercial, sender, brand-subdomain, pacing, health, circuit, or provider control.

One authority, one hot path

The old failure mode in sending systems is copied gate logic: campaign code checks one set of conditions, flows check another, transactional sends check a third, and the provider adapter grows an emergency bypass. Tests then prove whichever copy they happened to call.

Nitrosend uses one delivery authority for previews, reservations, dispatch authorization, commitment, and release. Campaigns, flows, transactional messages, and test traffic use explicit workload policies inside that authority. No sender or provider adapter accepts a general-purpose skip flag.

audience snapshot
   v
one admission authority -- reserve exact commercial + sender headroom
   v
set-based outbox preparation -- no per-recipient Ruby policy work
   v
batched provider dispatch -- capability checked immediately before call
   v
per-reservation settlement -- exact billing + capacity conservation

The safety model is durable without becoming the throughput bottleneck. Content and sender vetting are materialized before bulk dispatch. New or changed senders and content are checked rigorously, including synchronous model review on the first qualifying send. Older established senders reuse valid evidence and are re-vetted only when the sender, content, policy, or evidence epoch changes. The campaign fire lane performs set-based claims and updates rather than per-recipient Ruby policy work.

Reservations make the arithmetic honest

A large campaign does not merely read a counter and hope another worker does not race it. Admission reserves exact headroom before messages become provider-eligible. Dispatch binds messages to that reservation. Settlement commits only accepted provider outcomes, releases known failures, and leaves ambiguous provider ownership explicit until reconciliation.

That gives the system conservation rules it can enforce:

• no provider call without a current persisted dispatch capability;
• no message can spend more capacity than its reservation;
• one rejected reservation cannot poison successful settlements in the same batch;
• billing and capacity settle from the same accepted dispatch units;
• a stop or cancellation invalidates queued work without inventing outcomes.

Pacing is not a second gate

Pacing shapes work that admission has already bounded. It does not mint capacity, bypass the commercial plan, or reinterpret sender trust. The canonical status surface reports pacing alongside each capacity control so clients can show why work is delayed without building private policy.

Provider throughput is also an input, not a marketing promise. Nitrosend batches calls to the provider's native limits and keeps independent work in flight, but it stays inside current provider capacity and circuit state. When a provider is ambiguous, the reservation stays provider-owned until a reconciler establishes the outcome.

The performance release bar

Safety code does not belong as per-recipient object churn on the hot path. The release benchmark compares the isolated new system with the existing system on equivalent data and workload. The new campaign path does not ship unless it remains more than twice as fast as the accepted previous-system baseline while preserving the same conservation, provider-capability, vetting, and settlement rules.

That benchmark is a release gate, not a claim that every customer's provider will deliver twice as quickly. Provider quotas, current sender headroom, and pacing still determine elapsed delivery time. It means the Nitrosend side of the path leaves materially more headroom instead of spending safety on latency.

What to ask any high-volume platform

1. Does list size silently grant sending trust?
2. Can two workers overspend the same capacity?
3. Can any provider adapter send without a persisted authorization?
4. Are safety and billing set-based on the hot path?
5. Can one failed settlement rewrite successful outcomes?
6. Does a sender's reputation stay bound to that exact identity?
7. Can the operator stop a send and prove what did and did not cross the provider boundary?

Throughput matters. A system you cannot account for at speed is not high-performance infrastructure; it is merely fast at losing the plot.

Common questions

Moving serious volume? Tell us the audience, sender history, and provider shape. Start free, or reach out for a staged migration plan.