Ограничението на TPS нарежда на опашка — без тихо изтриване

Ограничението на TPS нарежда на опашка — без тихо изтриване.

Разбиране на лимитите на TPS и механиката на опашките

При изпращане на големи обеми OTP и SMS кампании, достигането на лимита за транзакции в секунда (TPS) е неизбежно. В професионална CPaaS среда с бял етикет (white-label), превишаването на този лимит никога не трябва да води до тихо изтриване на съобщения. Вместо това IOSOR внедрява строг механизъм за опашки. Когато изходящата ви скорост надвиши разпределения TPS, съобщенията се поставят в буфер в паметта. Това гарантира, че всяка дестинация E.164 се обработва по ред, без загуба на данни.

Защо тихото изтриване съсипва вашите показатели за доставка

Тихо изтриване възниква, когато API приеме съобщение, но го отхвърли, без да генерира DLR. Това нарушава логиката на вашето приложение, тъй като системата ви предполага, че съобщението се доставя. С IOSOR препълването задейства изрично състояние на опашка. Ако дълбочината на опашката надвиши праговете за безопасност, API връща статус за ограничаване на скоростта или нарежда елемента на опашка с изчакващ статус. Винаги ще получавате актуализация чрез уебхук или незабавна API грешка, никога празно пространство.

Блокиране на средства в счетоводния регистър и JIT присвояване на номера

За да поддържа абсолютна финансова точност, IOSOR използва предплатена счетоводна система. Когато съобщение влезе в опашката, върху баланса ви се поставя временно блокиране. Ако заявявате нови номера, нашата JIT (Just-In-Time) система присвоява ресурса E.164 и прилага MRC само когато маршрутът е активен. Това предотвратява изтичане на баланс. Изискваме минимален предплатен баланс от USD 20, за да поддържаме акаунта ви активен, и инициираме преглед при достигане на USD 1.000/месец за оптимизиране на вашите персонализирани TPS лимити.

Статуси на уебхукове за наредена на опашка и ограничена клинтелна активност

Всяка промяна в състоянието на съобщението се излъчва чрез уебхук. Когато съобщението е ограничено, статусът му се променя на 'queued' вместо 'failed'. След като капацитетът на TPS позволи, съобщението се изпраща и статусът преминава в 'sent' и накрая в 'delivered' при получаване на DLR от оператора. Ако потребител отговори със STOP, системата незабавно спира следващите елементи на опашката към тази дестинация, като връща статус 'skipped', за да предотврати нарушения на правилата.

Свързани ресурси и дълбочина на опашката

За да оптимизирате пропускателната си способност и да разберете как лимитите на опашката си взаимодействат с вашите уебхукове, прегледайте тези технически ръководства:

• Препълване на опашката: спиране, без тихо изтриване
• Подтискане в кампании: пропуснатото не е неуспешно в счетоводния регистър
• Ограничаване на уебхук импулсите за защита на получателите

Тези ресурси обясняват как да управлявате пиковия трафик и да конфигурирате вашите крайни точки за обработка на отчети за доставка с висока едновременност.

Започнете с IOSOR

Проверете вашите линтове за TPS и праговете на дължината на опашката в конзолата на IOSOR, преди да пуснете голям обем трафик. Настройте своя уебхук слушател да улавя изричния преход в състояние 'в опашка', така че приложението ви правилно да разпознава ограничените заявки. Уверете се, че вашият бекенд разпознава активните задържания по легера за съобщенията в опашката, вместо да третира диспеча с ограничена скорост като липсващи доклади за доставка.

Обобщение IOSOR

Превишаването на вашия лимит за TPS в IOSOR никога не води до не проследени тихи загуби или непотвърдена загуба на съобщения.