Как разделить очереди OTP и массовых SMS без задержек кодов

Разделите коды входа и массовые SMS на отдельные очереди, затем закрепите за кодами часть доступной скорости отправки. Начните с проверки общего лимита у провайдера: без этого даже разные очереди будут конкурировать за один канал. OTP — это одноразовые коды для входа или подтверждения действия. Ниже разберём, где возникает задержка, как настроить приоритет и какие показатели проверить, чтобы рекламная рассылка не занимала весь ресурс SMS-шлюза.

Почему массовая рассылка задерживает коды входа?

Представим интернет-магазин: сотрудник запускает рассылку об акции, а покупатель в это время запрашивает код входа. Если приложение складывает все SMS в общую очередь и забирает их по порядку, код ждёт, пока обработчик отправит сообщения перед ним. Провайдер ещё не видел этот запрос, хотя покупатель уже ждёт SMS.

Есть и другое узкое место: приложение быстро отправляет запросы, но упирается в лимит шлюза. При превышении договорной скорости провайдер может поставить запросы в очередь или отклонить их; конкретное поведение нужно уточнить для своего подключения. Поэтому отдельная очередь внутри магазина сама по себе не обеспечивает приоритет на стороне провайдера (источник: smpp.by, технические материалы).

Проследите путь одного кода: создание задачи, ожидание в очереди, отправка в шлюз, ответ шлюза и статус доставки. Эти события нужно различать. Ответ о приёме запроса ещё не означает, что телефон получил сообщение.

Для начала попросите разработчика показать, где именно ждёт OTP во время рассылки. Если задержка возникает до обращения к шлюзу, меняйте обработку очереди. Если запрос уже принят шлюзом, проверяйте маршрут и доступную скорость вместе с провайдером.

Как настроить отдельную очередь для OTP?

Выделите кодам собственный путь обработки: очередь и обработчик, который забирает задания из неё. Массовая рассылка не должна занимать все рабочие процессы приложения. Иначе разные названия очередей ничего не изменят: код всё равно будет ждать свободного исполнителя.

1. Помечайте задачу как OTP в момент её создания. Тип сообщения должен задавать сценарий входа, чтобы обработчику не приходилось угадывать назначение по тексту SMS.
2. Направляйте OTP в отдельную очередь. Проверьте, что массовые сообщения туда не попадают.
3. Выделите обработчик для этой очереди. Он должен получать ресурс даже тогда, когда обработчики рассылки заняты.
4. Задайте срок актуальности задания. Перед отправкой обработчик должен отбрасывать код, который уже нельзя использовать.
5. Ограничьте скорость массовой рассылки. Согласуйте её с общей пропускной способностью и запасом для кодов.

Срок ожидания задания и срок действия кода связаны между собой. Нет смысла отправлять SMS после того, как приложение уже перестало принимать этот код. При повторном запросе также задайте понятное правило: какие задания ещё актуальны и какие нужно отменить.

Приоритетная очередь защищает от конкуренции с рассылкой, но сама по себе не ограничивает поток запросов на коды. Если кто-то запускает частые отправки, он занимает тот же ресурс. Эту задачу отдельно разбирает материал о том, как защитить SMS API от накрутки OTP и лишних расходов.

Как распределить скорость API или SMPP между очередями?

Начните с вопроса провайдеру: к чему привязан лимит отправки в вашем подключении? Он может действовать на уровне учётной записи или соединения; точные условия зависят от сервиса. Дополнительное подключение не стоит считать дополнительной пропускной способностью без подтверждения провайдера.

Настройте общий ограничитель скорости перед SMS-шлюзом. Он должен учитывать отправки из обеих очередей и оставлять ресурс для OTP. Когда появляется код, обработчик рассылки снижает темп. При этом массовые задания должны продолжать получать свою долю ресурса, иначе поток кодов сможет отложить рассылку на неопределённый срок.

Размер резерва выбирайте по наблюдаемому потоку запросов на вход. Смотрите на периоды нагрузки, когда коды запрашивают одновременно. Если статистики ещё нет, сначала проведите тест очередей и согласуйте стартовые ограничения с провайдером. Универсального соотношения для интернет-магазина и сервиса записи нет.

Для SMPP отдельно проверьте window size, или размер окна. Это число запросов, которые клиент отправил и для которых ещё не получил ответ о приёме. Малое окно при заметной задержке ответов ограничивает скорость: клиент ждёт подтверждений, хотя мог бы передавать следующие запросы. Увеличение окна помогает использовать канал, но не повышает договорной лимит (источник: SMS Центр, «Как увеличить скорость рассылок по SMPP-подключению»).

В SMPP ответ на запрос отправки называется submit_sm_resp. Его нельзя путать с DLR, отчётом о доставке: окно отправки освобождают по ответам на запросы, а доставка на телефон происходит отдельно. Если приложение ждёт DLR перед следующей отправкой, сначала проверьте эту логику, затем меняйте размер окна.

Для API-интеграции действует тот же принцип: отдельные очереди, контроль общего темпа и обработка ограничений шлюза. На уровне SMPP-шлюза стоит выяснить, поддерживает ли провайдер приоритеты для разных потоков. Именно здесь интеграция приложения и настройка шлюза должны работать согласованно.

Как проверить, что разделение очередей работает?

Запустите тест с потоком массовых сообщений и добавьте запросы OTP во время его обработки. Сначала это можно сделать на тестовом шлюзе или имитаторе ответов, чтобы проверить собственную логику без реальной рассылки. Подготовить такую проверку поможет инструкция по тестированию SMS-интеграции без платных отправок.

Сравнивайте поведение кодов при пустой очереди рассылки и при её заполнении. Успешный результат для приложения: OTP не ждёт завершения массовой отправки и получает доступ к выделенному ресурсу. Доставку на телефон проверяйте отдельно, потому что имитатор не воспроизводит работу оператора.

• Время ожидания OTP в очереди: от создания задачи до начала обращения к шлюзу.
• Время ответа шлюза: от отправки запроса до подтверждения приёма или ошибки.
• Возраст самого старого задания: он помогает заметить очередь, которую обработчик перестал разбирать.
• Ошибки ограничения скорости и повторные попытки: они показывают, соблюдает ли приложение лимит.
• Статусы доставки: они нужны для проверки этапа после приёма сообщения шлюзом.

Среднее время ожидания способно скрыть отдельные долгие задержки. Поэтому смотрите и на самые медленные задания, а также на коды, срок которых истёк до отправки. В аналитике трафика разделяйте OTP и массовые SMS: общий график не покажет, какой поток занял доступную скорость.

Добавьте в тест временный отказ шлюза. Повторные попытки не должны идти непрерывно и вытеснять свежие коды. Перед каждым повтором проверяйте актуальность задания, а при неясном результате отправки учитывайте риск дубля: отсутствие ответа ещё не доказывает, что шлюз не принял SMS.

Типичные ошибки при разделении SMS-очередей

• Создали разные очереди, но оставили общий занятый обработчик. Выделите OTP отдельный ресурс для выполнения задач.
• Открыли дополнительное SMPP-соединение и рассчитывают на рост скорости. Уточните общий лимит учётной записи у провайдера.
• Увеличили окно SMPP без проверки ограничений. Сначала сопоставьте задержку ответов, текущую скорость и ошибки шлюза.
• Повторяют отправку без пауз и проверки срока кода. Ограничьте повторы и удаляйте неактуальные задания.
• Считают приём шлюзом успешной доставкой. Отдельно отслеживайте ответы на запросы и DLR.

Разделение работает, когда приложение даёт кодам отдельный ресурс, а шлюз пропускает их в пределах согласованных ограничений. Это можно проверить по времени ожидания OTP во время массовой отправки. Следующий шаг на две минуты: отправьте разработчику вопрос «OTP и рассылка используют общую очередь, общий обработчик или общий лимит шлюза?»