Limites de TPS et files d'attente — Pas de suppression silencieuse

Limites de TPS et files d'attente — Pas de suppression silencieuse.

Comprendre les limites de TPS et les mécanismes de file d'attente

Lors de l'envoi de campagnes OTP et SMS à fort volume, atteindre une limite de transactions par seconde (TPS) est inévitable. Dans un environnement CPaaS professionnel en marque blanche, le dépassement de ce plafond ne devrait jamais se traduire par une perte silencieuse de messages. Au lieu de cela, IOSOR implémente un mécanisme de file d'attente strict. Lorsque votre débit sortant dépasse le TPS alloué, les messages sont placés dans un tampon en mémoire.

Pourquoi les suppressions silencieuses ruinent vos indicateurs de livraison

Une suppression silencieuse se produit lorsqu'une API accepte une charge utile mais la rejette sans générer de rapport de livraison (DLR). Cela brise la logique de votre application, car votre système suppose que le message est en transit. Avec IOSOR, un débordement déclenche un état de file d'attente explicite. Si la profondeur de la file d'attente dépasse les seuils de sécurité, l'API renvoie un statut de limite de débit ou met l'élément en file d'attente avec un statut en attente.

Retenues sur le grand livre et attribution de numéros JIT

Pour maintenir une précision financière absolue, IOSOR utilise un système de grand livre prépayé. Lorsqu'un message entre dans la file d'attente, une retenue temporaire est appliquée sur votre solde prépayé. Si vous approvisionnez de nouveaux numéros, notre système JIT (Just-In-Time) attribue la ressource E.164 et n'applique les frais mensuels récurrents (MRC) que lorsque la route est active. Cela évite les fuites de solde.

Statuts des webhooks pour le trafic mis en file d'attente et régulé

Chaque transition d'état de message est diffusée via webhook. Lorsqu'un message est régulé, son statut passe à 'queued' plutôt qu'à 'failed'. Une fois que la capacité de TPS le permet, le message est envoyé, et le statut passe à 'sent', puis à 'delivered' dès réception du DLR de l'opérateur. Si un utilisateur répond par STOP, le système interrompt immédiatement les envois en file d'attente vers cette destination, renvoyant un statut 'skipped' pour éviter toute violation de conformité.

Ressources connexes et profondeur de la file d'attente

Pour optimiser votre débit et comprendre comment les limites de file d'attente interagissent avec vos webhooks, consultez ces guides techniques :

• Saturation de file : arrêt, pas de suppression silencieuse
• Suppressions dans les campagnes : ignoré n'est pas un échec sur le grand livre
• Limitation des rafales de Webhook pour protéger les récepteurs

Ces ressources expliquent comment gérer les pics de trafic et

Commencez avec IOSOR

Examinez vos limites de transactions par seconde et vos seuils de profondeur de file d attente dans la console IOSOR avant de lancer un trafic à fort volume. Configurez votre écouteur de webhook pour capturer la transition explicite vers l état mis en file d attente afin que votre application identifie correctement les requêtes bridées. Vérifiez que votre backend reconnaît les retenues de solde actives sur les messages en attente, plutôt que de traiter les envois limités par le débit comme des rapports de livraison manquants.

À retenir — IOSOR

Dépasser votre plafond de débit dans IOSOR n entraîne jamais de pertes silencieuses non suivies ou de disparitions de messages sans accusé. La plateforme applique un flux explicite de mise en attente, préservant votre charge utile, appliquant une retenue temporaire et diffusant le statut jusqu à ce que la capacité de traitement redevienne disponible.