Очередь SMS отделяет бизнес-систему от шлюза и помогает отправлять сообщения без перегрузки API или SMPP-сессии. В статье разберём, как устроить такую очередь, зачем нужен rate limit, что делать при временной ошибке и как расставлять приоритеты. После настройки вы сможете разделять срочные уведомления и обычные рассылки, повторять неудачные попытки без дублей и видеть, где сообщение задержалось: в приложении, очереди или у SMS-поставщика.
Зачем бизнесу очередь SMS между приложением и шлюзом?
Когда интернет-магазин, сервис записи или внутренняя система отправляет SMS, приложение часто формирует сразу много запросов. Например, после изменения статуса заказа десятки сообщений могут уйти почти одновременно. Если передавать их напрямую в API, приложение начнёт зависеть от скорости ответа шлюза. При работе через SMPP похожая проблема возникает, когда клиентская система пытается отправить больше сообщений, чем разрешает текущая сессия или канал.
Очередь принимает задачу быстро, а отправку выполняет отдельный обработчик. В запись попадают номер получателя, текст, идентификатор сообщения, время создания и текущий статус. Рабочий процесс забирает задачи по одной или небольшими партиями, отправляет их через API или SMPP и сохраняет результат.
Такой подход даёт несколько практических преимуществ:
- приложение не ждёт завершения каждой отправки;
- временный сбой шлюза не теряет уже созданные задачи;
- скорость отправки можно ограничить без изменения бизнес-логики;
- срочное уведомление можно поставить выше обычной кампании;
- статусы и ошибки остаются доступными для аналитики трафика.
Для малого бизнеса достаточно начать с одной очереди и отдельного обработчика. Сложную систему с несколькими узлами имеет смысл добавлять после появления реальной нагрузки, а не на этапе первой интеграции.
Как работает rate limit в API и SMPP?
Rate limit ограничивает число запросов или сообщений за определённый промежуток времени. Лимит задаёт не только приложение: его могут устанавливать API-поставщик, SMS-шлюз, конкретный маршрут или параметры SMPP-подключения. Поэтому скорость нельзя выбирать «на глаз». Её берут из технических условий подключения и проверяют тестовой отправкой.
В API обработчик обычно считает запросы за секунду или минуту. Если достигнут предел, новая задача остаётся в очереди и ждёт следующего окна. Ответ с временной ошибкой тоже не повод сразу повторять запрос: несколько параллельных повторов создадут дополнительную нагрузку.
В SMPP отправитель поддерживает соединение и передаёт сообщения через операции протокола. Для интеграции нужно учитывать доступное количество параллельных запросов, подтверждения отправки и состояние bind-сессии. Документация SMPP-шлюза обычно описывает параметры подключения, отправку SMS и статусы доставки; например, при настройке важно сверить версию протокола, поля сообщения и формат DLR.
| Ситуация | Действие очереди | Что сохранить |
|---|---|---|
| Лимит API достигнут | Поставить задачу на короткую задержку | Код ответа и время следующей попытки |
| SMPP-сессия разорвана | Приостановить отправку и восстановить соединение | Статус сессии и идентификатор сообщения |
| Временная ошибка шлюза | Повторить по расписанию | Количество попыток и последнюю ошибку |
| Постоянная ошибка номера или параметров | Завершить задачу без повторения | Финальный статус и причину отказа |
Полезно разделить ограничение на два уровня. Первый действует на весь отправляющий процесс, второй задаёт безопасный предел для отдельного маршрута или соединения. Так очередь не ускоряет одну часть системы за счёт перегрузки другой.
Как настроить повторы и backpressure без дублей?
Backpressure, или обратное давление, означает, что система снижает подачу новых сообщений, когда отправляющий канал не успевает их обработать. Очередь при этом растёт, но обработчик не создаёт бесконечный поток запросов. Для бизнеса важнее предсказуемая задержка и сохранность задач, чем попытка отправить всё мгновенно.
Каждая задача должна иметь внутренний идентификатор. Перед отправкой обработчик переводит её из статуса «ожидает» в «в работе», а после ответа сохраняет результат. Если процесс прервался между отправкой и записью статуса, повторный запуск должен проверить идентификатор операции и правила идемпотентности поставщика. Без этого одно уведомление может уйти дважды.
Повторы делят на временные и постоянные. К временным относят недоступность соединения, превышение лимита и кратковременный сбой API. Для них задают ограниченное число попыток и увеличивающуюся паузу. Постоянные ошибки параметров, некорректного номера или формата сообщения отправлять заново бессмысленно.
Состояния удобно описать явно:
- queued — задача ждёт обработки;
- processing — обработчик отправляет сообщение;
- accepted — шлюз принял запрос;
- delivered — получен статус доставки;
- retry — нужна следующая попытка;
- failed — повтор запрещён или исчерпан лимит попыток.
Статус «accepted» не стоит считать доставкой. Он показывает, что запрос принят системой отправки. Фактический результат приходит позднее через DLR или webhook, поэтому его нужно связать с исходной задачей по идентификатору сообщения.
Отдельно проверьте защиту от дублей при повторной обработке. Практические сценарии такой защиты разобраны в материале почему SMS отправляется дважды и как защитить API и SMPP от дублей.
Как расставить приоритеты в очереди SMS?
Одна общая очередь подходит для простого проекта, но обычная массовая отправка способна задержать критичное уведомление. Поэтому задачи распределяют по приоритетам. Срочными могут быть сообщения о готовности заказа, переносе записи или изменении времени доставки. Обычные информационные сообщения и плановые серии отправляют после них.
Есть два понятных варианта. Первый, отдельные очереди для разных типов сообщений. Обработчик сначала проверяет срочную очередь, затем обычную. Второй, единая очередь с числовым приоритетом и временем создания. В обоих случаях добавляют ограничение, чтобы поток срочных задач не блокировал всё остальное.
| Приоритет | Пример задачи | Правило обработки |
|---|---|---|
| Высокий | Перенос визита или готовность заказа | Отправлять при первой доступной попытке |
| Обычный | Подтверждение стандартного действия | Обрабатывать в общей очереди |
| Низкий | Плановое информационное сообщение | Отправлять после срочных задач и в пределах лимита |
Приоритет должен описывать бизнес-смысл, а не желание конкретного отдела отправить сообщение первым. Если все задачи получают высший приоритет, очередь фактически теряет управление. Для начала достаточно двух уровней: срочный и обычный.
Какие показатели нужно контролировать?
Без мониторинга очередь превращается в скрытое место задержек. На дашборде полезно показывать размер очереди, возраст самой старой задачи, скорость обработки и долю повторов. Отдельно отслеживают ошибки API, разрывы SMPP-сессии и разницу между принятыми сообщениями и полученными статусами доставки.
Пороговые значения зависят от сценария, поэтому их фиксируют после тестов. Если очередь постоянно растёт, обработчик получает слишком много задач, лимит канала выбран неверно или ошибки повторяются без паузы. Если задачи быстро исчезают, но DLR не приходят, проверяют связь идентификаторов, формат статусов и обработку webhook.
Для диагностики полезно хранить время постановки задачи, время каждой попытки, ответ шлюза и финальный статус. Эти данные помогают отличить перегрузку собственной системы от технического сбоя оператора. Общий подход к контролю интеграции описан в материале как настроить мониторинг SMS-интеграции в 2026 году.
Типичные ошибки при построении очереди
- Отправка всех задач параллельно без ограничения скорости.
- Повтор любого отрицательного ответа, включая постоянные ошибки.
- Отсутствие уникального идентификатора сообщения.
- Смешивание срочных уведомлений с плановой массовой отправкой.
- Удаление задачи сразу после ответа API без ожидания статуса доставки.
- Контроль только размера очереди без проверки возраста самой старой задачи.
3 шага, которые можно сделать на этой неделе:
- Описать статусы задачи и разделить ошибки на временные и постоянные.
- Добавить rate limit, ограниченное число повторов и уникальный идентификатор операции.
- Разделить срочные и обычные сообщения, затем проверить очередь тестовыми отправками и DLR.
Для проекта на API или SMPP этого набора достаточно, чтобы начать с управляемой схемы: приложение создаёт задачи, очередь регулирует скорость, шлюз возвращает результат, а аналитика показывает задержки и ошибки. Если интеграция требует отдельного SMPP-шлюза, подключения по API и контроля трафика, такую архитектуру можно собрать вокруг технической площадки smpp.by без изменения бизнес-системы.
