why most architectures fail at 100K/day
Most US teams handle 10,000 verification messages a month without issue. A single synchronous HTTP call to an SMS API, a basic retry loop, and you're done. The trouble starts around 100,000 messages. At that volume, three things compound simultaneously:
- Carrier rate limits — AT&T and T-Mobile enforce per-second and per-minute throughput caps on 10DLC routes that are not documented in their public-facing marketing materials but are enforced at the network level.
- A2P 10DLC filtering — Unregistered or low-trust campaigns face aggressive message suppression and per-message surcharges. Telnyx's published fee schedule shows T-Mobile charging approximately $0.011–$0.012 per message for unregistered traffic, and AT&T around $0.020–$0.021. Registered 10DLC costs far less but requires campaign vetting.
- Retry storms — When a synchronous API blocks on carrier acknowledgment, a spike in traffic exhausts your thread pool. Retries pile up on top of new sends, creating a feedback loop that collapses delivery rates.
At one million messages a month, you are in a different game entirely. You need dedicated short codes or pooled 10DLC campaigns with high throughput tiers. If you rely on standard tier-1 legacy aggregators without direct carrier connections, you will find yourself fighting AT&T and T-Mobile every single day just to keep delivery rates above 80%.
This is where ITNIO TECH differs from platforms like Twilio. We process tens of millions of messages daily across 200+ countries with direct connections to 100+ operators. That means fewer intermediary hops. When you route bulk OTP traffic through legacy platforms, you are often routing through an aggregator that routes through another aggregator. Direct-to-carrier APIs reduce latency, improve delivery confirmation accuracy, and give you more control over carrier-specific routing logic.
Two cost layers, and only two
US OTP cost equals the
verification fee plus the
SMS channel fee. That's it. Everything else is markup.
Twilio's published US pricing is rigid: $0.05 per successful verification plus $0.0083 per US SMS. That is the standard retail benchmark.
Vonage offers two models: Verify Conversion (platform fee + channel fee regardless of outcome) and Verify Success (charges only on successful verifications, but restricted to enterprise volume accounts).
ITNIO TECH does not publish rigid per-message rates for the US market. We quote by volume. If you know your monthly send count and destination mix, this is a structural advantage — you are not paying retail markups layered on top of carrier fees. You pay for your actual scale.
Carrier filtering is where naive batch sending dies
The 10DLC ecosystem in the US is governed by The Campaign Registry (TCR), which assigns each campaign a
trust score that directly determines throughput limits and filtering behavior. A low-trust campaign may be throttled to 15 messages per second; a high-trust campaign can reach 450+ MPS. This is not optional — it is enforced at the carrier gateway level.
Unregistered 10DLC traffic is penalized heavily. Telnyx's published schedule lists T-Mobile at roughly $0.011–$0.012 per message for unregistered traffic, and AT&T around $0.020–$0.021. Registered 10DLC costs far less per message, but the registration process on legacy platforms is often a bureaucratic bottleneck: brand registration, campaign registration, use-case classification, sample message submission, and carrier vetting that can take 2–6 weeks.
ITNIO TECH maintains strict US carrier compliance and provides localized integration support to get your 10DLC campaigns approved. We manage the TCR registration workflow end-to-end, including brand vetting, campaign use-case classification, and carrier-specific sample message optimization. If you are doing batch OTP dispatch to US consumers without a provider that actively manages 10DLC compliance, you are paying unregistered surcharges on every message.
how a flash-sale signup spike exposed synchronous architecture
In 2024, direct-to-consumer brand
Gymshark experienced a well-documented technical outage during a major product drop. When a highly anticipated collection launched, traffic surged far beyond forecasted levels. The company's infrastructure — built on a combination of third-party services — could not handle the concurrent load. Customers reported being unable to complete purchases, and the brand publicly acknowledged the issue on social media, apologizing for the disrupted experience.[Gymshark public statements, 2024]
While Gymshark's specific failure involved checkout infrastructure rather than SMS verification alone, the root cause is the same pattern that breaks most SMS verification systems at scale:
synchronous blocking under burst traffic. When thousands of users simultaneously trigger verification flows — whether at checkout or during account creation — any component that waits for an external API response before proceeding becomes a single point of failure.
The engineering lesson is clear and directly applicable to SMS verification architecture:
- Synchronous API calls to SMS providers block thread pools. If your backend waits for the carrier to respond before returning to the user, 10,000 simultaneous signups will exhaust your connection pool in seconds.
- Retries amplify the problem. When users don't receive codes and click "resend," each retry adds more load to an already saturated system.
- The fix is asynchronous queuing. Decouple the user-facing request from the SMS send operation. Accept the request, enqueue it, return immediately, and let a worker pool process sends at a rate your SMS provider and the carrier network can absorb.
A representative architecture that addresses this pattern:
Key design decisions:
- Idempotency keys prevent duplicate sends when users click "resend" rapidly.
- Per-carrier rate limiting respects AT&T/T-Mobile throughput caps and avoids triggering filtering.
- Exponential backoff on retries prevents retry storms from overwhelming the system.
- Asynchronous status callbacks let you track delivery without blocking the send path.
ITNIO TECH's API supports asynchronous status callbacks natively, and our high-concurrency endpoint is designed to handle burst traffic without artificial throttling. In representative deployments using this architecture, teams have observed retry rates drop from approximately 20%+ to single digits, with corresponding improvements in verification completion rates and per-message cost efficiency.
A reference architecture for 100K OTP/day
Here is the minimum viable architecture for sending 100,000+ OTPs per day to US consumers:
- Queue-first dispatch. Never send SMS synchronously from your request handler. Use Redis, RabbitMQ, or Kafka to buffer sends.
- Idempotency key. Hash the user identifier + request context to prevent duplicate sends on retry.
- Per-carrier rate limiter. Maintain separate rate-limit buckets for AT&T, T-Mobile, and Verizon based on number prefix (NPA-NXX lookup). Respect each carrier's MPS cap for your 10DLC campaign tier.
- Retry with exponential backoff. Start at 2 seconds, double on each retry, cap at 5 attempts. Log failures for analysis.
- Carrier-aware routing. Use an NPA-NXX database to determine the home carrier for each number and route accordingly. This is especially important when using multiple SMS providers with different carrier relationships.
- Status callback handling. Process delivery receipts asynchronously. Do not poll.
- Monitoring and alerting. Track delivery rate, retry rate, cost per delivered message, and carrier-specific failure codes. Set alerts for anomalies.
ITNIO TECH provides API documentation, batch-send task splitting, and carrier-prefix routing support to implement this architecture. We do not throttle you into oblivion because you are sending at scale — our infrastructure is built for high-concurrency OTP workloads.
Frequently Asked Questions
What causes a bulk OTP API to crash at peak volume?Synchronous blocking. If your backend waits for the carrier to respond before returning to the user, a traffic spike will exhaust your thread pool or connection pool. The solution is an asynchronous queue (Redis, RabbitMQ, Kafka) with idempotency keys and a worker pool that processes sends at a controlled rate.
How does US 10DLC registration impact bulk throughput?Unregistered traffic is aggressively filtered and surcharged by T-Mobile and AT&T. Registered campaigns receive a trust score from The Campaign Registry that determines your throughput tier. A Standard brand campaign may be limited to 15 MPS; a high-throughput tier can reach 450+ MPS. Registration is mandatory for reliable delivery, and the vetting process can take 2–6 weeks. Plan accordingly.
What volume thresholds trigger custom pricing with ITNIO TECH?ITNIO TECH operates on a volume-tiered model with no fixed public threshold. If your monthly OTP volume exceeds 50,000 messages, standard retail fees from legacy platforms become increasingly inefficient relative to volume-based pricing. Request a quote with your monthly send count and destination mix for a custom rate.
How do I choose between short codes and 10DLC for US verification?Short codes offer the highest throughput (up to 3,000 MPS) and the best deliverability, but they are expensive ($500–$1,000/month for a dedicated code) and take 8–12 weeks to provision. 10DLC is cheaper and faster to register but has lower throughput caps and is subject to campaign trust scoring. For most brands sending under 500K messages/month, 10DLC is the right choice. For high-volume senders, a dedicated short code or a pooled 10DLC strategy may be more cost-effective.
Data Sources:
- Twilio Verify pricing: https://www.twilio.com/en-us/verify/pricing
- 10DLC carrier fees (Telnyx): https://support.telnyx.com/en/articles/5634625-10dlc-fees-and-charges
- ITNIO TECH coverage: https://m.itniotech.cn/about-us/
