Очередь SMS-сообщений: как выдержать пиковую нагрузку без потерь

Очередь SMS-сообщений отделяет бизнес-событие от внешнего вызова провайдера. Сайт или CRM быстро фиксирует задачу, а фоновые обработчики отправляют её с контролируемой скоростью. Благодаря этому всплеск заказов, регистраций или массовых обновлений не превращается в таймауты для пользователей и потерянные уведомления.

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

Что должна разделять очередь

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

У системы появляются два контура:

1. Приём события. Проверить данные, создать устойчивую задачу и вернуть результат бизнес-операции.
2. Доставка. Получить задачу, вызвать SMS API, сохранить идентификатор и дождаться финального статуса.

Такой разрыв снижает связанность, но требует явных состояний. «Записано в очередь» не равно «принято провайдером», а «принято провайдером» не равно «доставлено абоненту».

Состав задачи

В задаче полезно хранить не только номер и текст. Минимальный набор включает:

• идентификатор бизнес-события и ключ идемпотентности;
• тип трафика: OTP, сервисный или массовый;
• получателя в нормализованном формате;
• идентификатор и версию шаблона, переменные;
• желаемое время отправки и крайний срок;
• приоритет и допустимый маршрут;
• число попыток и время следующей попытки;
• correlation ID для логов.

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

Гарантии доставки задачи

Большинство очередей работают по модели at-least-once: задача может прийти повторно, зато не исчезает после временного сбоя. Для SMS это означает обязательную идемпотентность. Воркер должен безопасно увидеть одно событие несколько раз и создать только одну внешнюю отправку.

Подтверждать задачу нужно после фиксации результата, а не сразу после чтения. Если процесс завершится между подтверждением и вызовом API, сообщение потеряется. Если он завершится после API, но до подтверждения, задача вернётся — поэтому общий idempotency key должен переживать перезапуск.

Отдельная таблица состояний или transactional outbox помогает согласовать изменение бизнес-данных и постановку события. Иначе заказ может сохраниться, а процесс упасть до записи в очередь.

Ограничение скорости

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

Практически используют token bucket или другой управляемый rate limiter. Лимиты удобно задавать отдельно по маршруту, отправителю и типу трафика. Если один оператор временно замедлился, это не должно останавливать все остальные направления.

Просто добавить воркеров недостаточно. При внешнем лимите большее число процессов увеличит конкуренцию и количество ошибок, но не фактическую пропускную способность.

Приоритеты и отдельные потоки

Код входа не должен ждать за рекламной кампанией из ста тысяч сообщений. Для критичных сценариев создают отдельные очереди или резервируют долю пропускной способности. Такое разделение продолжает общие принципы автоматизации SMS-уведомлений, но добавляет технические гарантии для пиков.

Важно не назначить всему максимальный приоритет. Уровни должны соответствовать измеримой срочности:

• критичный: короткоживущие коды и безопасность;
• высокий: изменение заказа или срочное сервисное событие;
• обычный: плановые уведомления;
• низкий: массовая коммуникация, которую можно растянуть.

Между уровнями нужна справедливость, чтобы низкая очередь не голодала бесконечно. Например, часть мощности всегда остаётся обычному трафику.

Старение очереди и TTL

Главная метрика очереди — не количество задач само по себе, а возраст самой старой готовой задачи. Десять тысяч сообщений могут быть нормой, если поток успевает их обработать. Сто сообщений с задержкой в час — уже авария для OTP.

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

Повторы и очередь ошибок

Временная ошибка переносит задачу на будущую попытку по политике backoff. Постоянная ошибка — например, неверный формат номера — не должна бесконечно занимать воркер. Её отправляют в dead-letter queue с понятным кодом причины.

Для повторов действуют ограниченное число попыток, растущая задержка с jitter, уважение Retry-After и общий дедлайн. Массовое ручное возвращение dead-letter задач запускают порциями, иначе оно создаст новый пик. Формат ошибок и ограничения заранее сверяют с документацией выбранного SMS-шлюза.

Наблюдаемость

Для каждой очереди отслеживайте:

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

Алерт по одной длине очереди часто шумит. Полезнее сочетать возраст, скорость роста и выполнение SLO. Если входящий поток стабильно выше исходящего, система должна предупредить до того, как задержка станет заметна клиентам.

Проверка аварийных режимов

Перед запуском остановите воркеры и накопите тестовые задачи, затем восстановите обработку с заданным лимитом. Проверьте, что приложение продолжает принимать бизнес-события, очередь не теряет записи, а восстановление не превышает возможности провайдера.

Отдельно смоделируйте дублирование задачи, падение воркера после внешнего вызова, 429, длительный 5xx и просроченный TTL. Начните с контролируемого контура и только затем переходите к небольшой тестовой SMS-рассылке на разрешённые номера.

Как оценить нужную производительность

Планируйте не по среднему дню, а по самому быстрому ожидаемому притоку. Если система создаёт 60 000 уведомлений за пять минут, среднее за сутки ничего не говорит о необходимой скорости дренирования. Зафиксируйте максимальный входящий поток, разрешённый возраст задачи и фактический лимит провайдера.

Простая оценка времени разбора backlog: количество ожидающих задач делится на доступную исходящую скорость за вычетом нового текущего потока. Если в очереди 30 000 задач, обработка даёт 100 в секунду, а новые приходят со скоростью 40, накопление будет уменьшаться примерно на 60 задач в секунду — больше восьми минут без учёта повторов. Такая оценка заранее показывает, успевают ли сообщения до TTL.

Масштабировать нужно весь путь: число воркеров, соединения с базой, скорость записи логов и callbacks. Узкое место после API способно накопить DLR, даже если отправка выглядит быстрой.

Владение и изменение конфигурации

У каждой очереди, лимита и dead-letter потока должен быть владелец. Изменение скорости или числа воркеров фиксируется как production-настройка и сопровождается причиной. Иначе временное увеличение после акции останется навсегда и проявится только при следующем сбое.

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

Итог

Хорошая очередь не просто складывает SMS «на потом». Она задаёт устойчивый контракт между бизнес-событием и внешней доставкой: хранит идентификатор, ограничивает скорость, разделяет приоритеты, безопасно повторяет временные ошибки и прекращает работу с устаревшими задачами. Именно эти свойства позволяют пережить пик без потерь, дублей и лавины запросов.