SMS-рассылки: Когда твой код должен кричать в трубку. Жесткие уроки интеграции

Сижу, смотрю на монитор. Серверный шум. Кофе холодный. Опять алерт свалился – очередь SMS тормозит. Знакомо? Если ты хоть раз интегрировал API для SMS рассылки, ты меня понял. Не та сказка, которую рисуют маркетологи. Реальность – это баги, таймауты и операторские блокировки. Готов поделиться грязными секретами. Опыт? Лет 15 в этом дерьме, простите, в этом прекрасном мире коммуникаций.

Вот смотри. Все хотят «просто отправлять смски». Нажал кнопку – улетело. Ха! Мечтатели. Главный подводный камень – интеграция. Не выбор провайдера, не цена даже. Как ты этот API для SMS рассылки в свою систему вживишь. Вот где собака зарыта. И зарыта глубоко. Вижу сплошь и рядом: берут первую попавшуюся доку, тыкают пример кода – и думают, готово. А потом – «почему не отправляется?», «почему долго?», «почему статусы не приходят?».

Забудь про REST для массовых отправок в реальном времени. Серьезно. Если у тебя не просто «раз в день уведомление», а поток – скажем, заказы, OTP, алерты – тебе нужна асинхронность. Очереди. RabbitMQ, Kafka, что угодно. Почему? Потому что провайдер может тупить. Его API может лечь. Сеть может моргнуть. А твоя синхронная ручка – встанет колом и потянет за собой всю систему. Видел такое на живом проекте интернет-магазина. Черная пятница. Заказы – как из пулемета. Их синхронная интеграция с «крутым» облачным SMS-сервисом легла через 20 минут. Таймауты, ошибки 500. Клиенты без подтверждений. Кошмар. Решение? Переписали на асинхрон. Вбросили сообщения в очередь – и worker’ы неспеша, упорно их выгребали. Система – выстояла. Моя точка зрения, хоть и спорная для любителей «быстрых» решений: для потока – только очередь. Без вариантов.

Теперь про провайдеров. Их дофига. Выбирать? Смотри не на цены в первую очередь (хотя и это важно), а на доставку статусов (DLR) и стабильность каналов. DLR – это святое. Без них ты слепой. Не знаешь, дошло ли. А операторы – те еще затейники. Блокируют короткие номера, длинные номера, контент… Запомни: один провайдер – одна точка отказа. Юзай мультилинк. Балансируй отправку между двумя-тремя операторами связи. Да, интеграций больше. Да, геморройнее. Но когда основной канал лег (а он ляжет, поверь), ты хотя бы не на нуле. У нас на проекте банковских OTP так спаслись не раз.

(Вспомнил коллегу Васю. Сидит, пьет чай с бергамотом. Вечно невыспавшийся. Лет 10 назад мы с ним на коленке поднимали рассылку для таксопарка. Сервер – старенький десктоп под виндой. Скрипт на PHP. И ничего, работало. Сейчас все сложнее. И надежнее должно быть.)

Жаргон? Поехали. SMPP – это наш «дедушка», но живой. HTTP API – проще, но для массовки не всегда. DLR – это твои глаза и уши. Sender ID – твое лицо (или имя). Баллансер – твоя страховка. Аптайм – твоя религия. Транзакльные сообщения (OTP, алерты) – святая святых, их доставка критична. Маркетинг – терпит чуть больше.

Реальный кейс с подлянкой. Клиент: сервис доставки еды. Интегрировали с топовым провайдером. Все тесты ок. В бое – часть SMS с кириллицей до абонентов МТС превращалась в кракозябры. Стандартные проверки кодировки (UTF-8!) не помогали. Оказалось, провайдер на своей стороне для «оптимизации» конвертил сообщения в GSM-03.38, но криво, если в тексте были одновременно русские буквы и, скажем, кавычки “ёлочки”. Фикс? Пинаем провайдера, чтобы отключили конвертацию на их стороне, и жестко выставили кодировку в заголовках запроса. Иногда провайдеры такие «помощники» – сами не рады.

Еще одна вещь, которую все игнорят: тестовая среда. Настоящая. Не отправка себе на три номера. А эмуляция нагрузки. Сотни, тысячи сообщений в минуту. Как твоя система, твои воркеры, твоя очередь – тянут? Как провайдер отвечает? Какие лимиты по RPS (запросов в секунду) он реально держит? Время слать тестовые сообщения – сейчас. Не когда клиенты ругаться начнут. Настрой алерты не только на «ошибки», но и на рост времени доставки. Если оно поползло вверх – жди беды. Мониторинг – твой лучший друг. Графаны, Zabbix – что угодно. Смотри на латенси (задержку) ответа API провайдера, на процент ошибок, на заполнение очереди.

Личное мнение? Терпеть не могу провайдеров, у которых в API нельзя явно указать приоритет сообщения. Особенно для транзакционок. Когда OTP валится в общую очередь с маркетингом – это ппц. Где логика? Приходится городить костыли. Или искать другого.

Про ценообразование и шаблоны… Это отдельная боль. Но не сегодня. Скажу только: читай договор как детектив. Особенно про блокировки и возвраты денег. И про DLR – обязаны ли они их гарантировать? Или это «как получится»?

Итог? API для SMS рассылки – это не волшебная таблетка. Это инструмент. Мощный, но сложный. Интеграция – ключ. Надежность – святое. Мониторинг – обязателен. Не наступай на грабли, по которым я уже прошелся. Тестируй жестко. Готовь запасные пути. И да, держи под рукой нервяки и кофе. Пригодится.

Автор статьи:
Дмитрий Кузнецов, старший инженер телеком-систем (17 лет в авралах), вытащил 50+ кривых SMS-интеграций, архитектор рассылочного хаба для «Почты России» (да, тот самый, что не падает)