Расчёт TPS и очередей SMS без задержки OTP

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

Сначала опишите профиль нагрузки

Число сообщений за месяц почти ничего не говорит о пике. Для расчёта нужны:

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

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

Сообщение и сегмент — разные единицы

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

Для оценки используйте:

segments_per_second = messages_per_second × average_segments_per_message

Среднего значения недостаточно. Посчитайте P95 числа сегментов и долю самых длинных шаблонов. Проверяйте итоговый текст после подстановки имени, суммы и ссылки: именно динамические поля часто переводят сообщение через границу сегмента.

Как оценить время очереди

Если в очереди накопилось Q сегментов, а доступная полезная производительность равна C, минимальное время опустошения примерно равно Q / C. На практике оставьте запас на колебания маршрута, повторы, служебный обмен и неравномерное распределение по операторам.

Например, очередь из 180 000 сегментов при устойчивой полезной скорости 1 000 сегментов/с опустеет не быстрее чем за три минуты. Для OTP это недопустимо, даже если средняя суточная мощность выглядит достаточной.

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

Разделяйте классы обслуживания

Одна FIFO-очередь проста, но создаёт head-of-line blocking: тысячи низкоприоритетных сообщений оказываются перед срочным кодом. Надёжная схема использует отдельные очереди и планировщик:

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

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

Лимиты существуют на нескольких уровнях

Общая мощность платформы не гарантирует ту же скорость для конкретного направления. Ограничения могут действовать на:

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

Для QuickTel опубликована производительность платформы до 8 000 SMS/с, но фактический показатель проекта зависит от маршрутов, текста, операторских ограничений и договора. Используйте эту цифру как верхнюю характеристику платформы, а не как обещание для любого направления. Критерии выбора интерфейса разобраны в сравнении SMPP и HTTP API.

Backpressure вместо неконтролируемого накопления

Когда входящий поток выше доступной отправки, система должна явно замедлить производителей. Возможные механизмы:

ограничение скорости по клиенту и классу;
ответ с признаком временной перегрузки;
квоты на объём очереди;
отбрасывание просроченных сообщений до отправки;
перенос массовой кампании на другое окно;
circuit breaker при деградации внешнего маршрута.

Не отправляйте OTP после истечения TTL только ради очистки очереди. Устаревшее сообщение создаёт путаницу и расход, но не приносит результата. Правила TTL и повторной выдачи связаны с архитектурой безопасного SMS OTP.

Масштабирование потребителей

Горизонтальное увеличение числа workers помогает, пока узкое место находится внутри вашего приложения. Оно не снимает внешний лимит платформы или оператора. Более того, слишком много параллельных потребителей может увеличить число отказов и повторов.

Масштабируйте по сочетанию метрик:

возраст старейшего задания;
скорость поступления и завершения;
число задач в работе;
доля throttling и временных ошибок;
задержка ответа внешнего API;
доступная квота конкретного маршрута.

Устанавливайте верхнюю границу экземпляров и плавное снижение после пика. Для SMPP учитывайте число сессий, window size и подтверждённые поставщиком ограничения.

Нагрузочный тест должен быть похож на производство

Тест одной короткой SMS на один номер показывает только базовую связность. Полезный сценарий включает:

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

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

Какие показатели принять

Зафиксируйте результаты по классам, а не одной общей цифрой:

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

Финальный DLR и бизнес-конверсию измеряйте отдельно — рекомендации есть в статье про доставляемость и метрики SMS. Рост технической скорости не полезен, если сообщения приходят поздно или неправильному сегменту аудитории.

Практический вывод

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

Перед подключением QuickTel подготовьте таблицу направлений, шаблонов, пиков и SLO. По ней можно согласовать интерфейс, квоты, резервирование и программу нагрузочного теста для конкретного проекта.

Пропускная способность SMS: TPS, очереди и приоритетный трафик