A TPS Cap Queues — It Does Not Drop Silent

A TPS Cap Queues — It Does Not Drop Silent.

Understanding TPS Caps and Queue Mechanics

When sending high-volume OTP and SMS campaigns, hitting a Transactions Per Second (TPS) limit is inevitable. In a professional white-label CPaaS environment, exceeding this cap should never result in silent message loss. Instead, IOSOR implements a strict queuing mechanism. When your outbound rate exceeds your allocated TPS, messages are placed in a memory-backed buffer. This ensures that every E.164 destination is processed in order without losing payload data.

Why Silent Drops Are Ruining Your Delivery Metrics

A silent drop occurs when an API accepts a payload but discards it without generating a DLR. This breaks your application logic, as your system assumes the message is in transit. With IOSOR, overflow triggers an explicit queue state. If the queue depth exceeds safety thresholds, the API returns a rate-limit status or queues the item with a pending state. You will always receive a webhook update or an immediate API error, never a black hole.

Ledger Holds and JIT Number Assignment

To maintain absolute financial accuracy, IOSOR uses a prepaid ledger system. When a message enters the queue, a temporary prepaid hold is placed on your balance. If you are provisioning new numbers, our JIT (Just-In-Time) system assigns the E.164 resource and applies the MRC only when the route is active. This prevents balance leakage. We enforce a USD 20 prepaid floor to keep your account active, and we initiate a soft review near USD 1,000/month to optimize your custom TPS limits.

Webhook Statuses for Queued and Throttled Traffic

Every message state transition is broadcasted via webhook. When a message is throttled, its status changes to 'queued' rather than 'failed'. Once the TPS capacity allows, the message is dispatched, and the status transitions to 'sent' and finally 'delivered' upon receiving the carrier DLR. If a user replies with STOP, the system immediately halts further queued items to that destination, returning a 'skipped' status to prevent compliance violations.

Related Resources and Queue Depth

To optimize your throughput and understand how queue limits interact with your webhooks, review these technical guides:

• Queue overflow: stop, do not silent-drop
• Suppressions in campaigns: skipped is not failed on the ledger
• Throttling Webhook Dispatch Bursts to Protect Receivers

These resources explain how to manage burst traffic and configure your endpoints to handle high-concurrency delivery reports.

Start with IOSOR

Inspect your TPS limits and queue depth thresholds in the IOSOR console before launching high-volume traffic. Configure your webhook listener to capture the explicit 'queued' state transition so your application correctly identifies throttled requests. Verify that your backend recognizes active ledger holds on queued messages rather than treating rate-limited dispatches as missing DLRs.

IOSOR takeaway

Exceeding your TPS cap in IOSOR never results in untracked silent drops or unacknowledged message loss. The platform enforces an explicit stop-and-queue workflow, keeping your payload intact, applying a temporary balance hold, and broadcasting the 'queued' status until throughput capacity becomes available.

Do monitor webhook status events to track messages transitioning seamlessly from queued to sent and delivered. Don't build timeout assumptions or mistake rate-limiting for dropped traffic when payload volume exceeds your assigned throughput cap.