Представьте: ваш бэкенд отправляет 10 000 SMS синхронно через HTTP. Каждый запрос длится 100–500 мс, сервер зависает на минуты, лимит Twilio (1 SMS/сек на обычном номере) превышается за несколько секунд, и половина сообщений уходит в ошибку 429. Бюджет потерян, пользователи недовольны. Мы видели такие сценарии десятки раз.
Недавно к нам пришёл проект с аудиторией 500 000 пользователей в России и СНГ. Клиент использовал Twilio, платя $0.08 за сообщение вместо $0.02 у локального провайдера. После миграции на SMSC и настройки очереди с лимитом 30 msg/s мы сократили расходы на 60% и устранили потери сообщений. На одном проекте мы снизили стоимость сообщения с $0.07 до $0.02, что сэкономило клиенту более $2000 в месяц.
Решение — асинхронная очередь с throttling и грамотный выбор шлюза. Ниже разберём архитектуру, которая выдержит нагрузку и не сожжёт бюджет.
За 7 лет мы интегрировали SMS-рассылку в 30+ мобильных приложений — от стартапов до enterprise-проектов с миллионными аудиториями. Наш опыт показывает: 80% проблем с доставкой связаны с неправильной настройкой rate limiting и выбором шлюза не по географии.
Какой шлюз выбрать?
Сравним популярные варианты:
| Шлюз | Особенности |
|---|---|
| Twilio | REST API, webhook-статусы, глобальное покрытие. Но дорог для СНГ — стоимость одного сообщения в 2-3 раза выше локальных операторов. |
| SMSC.ru | Дешевый для РФ/СНГ, нет webhook-статусов на дешёвых тарифах — приходится опрашивать сервер. |
| Infobip | Поддерживает SMS, Viber, WhatsApp. Onboarding сложный — нужна верификация документов. |
| Vonage (Nexmo) | Есть SDK для мобильных, но охват СНГ ограничен. |
Типичные лимиты шлюзов по скорости:
| Шлюз | Лимит на номер (SMS/сек) | Лимит на аккаунт (SMS/сек) |
|---|---|---|
| Twilio (обычный номер) | 1 | 10 |
| Twilio (короткий номер) | 100 | 1000 |
| SMSC.ru | 30 | 300 |
| Infobip | 50 | 500 |
Если ваша аудитория в России и СНГ — SMSC или аналоги. Для международных проектов — Twilio или Infobip. Мы помогаем выбрать оптимальный вариант под бюджет и требования.
Пример настройки воркера с Bull
const Queue = require('bull'); const smsQueue = new Queue('sms', 'redis://localhost:6379'); smsQueue.process(5, async (job) => { const { to, body } = job.data; await twilio.messages.create({ to, from, body }); await delay(1000 / 5); // 5 msg/sec }); Здесь 5 воркеров (concurrency) и задержка 200ms между сообщениями — итог 5 SMS/сек. Если нужно быстрее — увеличить concurrency, но не превышать лимит шлюза.
Как избежать rate limiting?
Rate limiting — главная проблема bulk-рассылок. Нарушение лимитов ведёт к блокировке и потере сообщений. Правильная архитектура: очередь задач (например, RabbitMQ или Redis + BullMQ) и воркеры с throttling. Каждый воркер забирает задачу, отправляет SMS, ждёт интервал, затем следующую. Для ускорения запускают несколько воркеров параллельно, контролируя общий throughput.
Почему нельзя отправлять SMS синхронно?
Попытка отправить 10 000 SMS в одном цикле HTTP-запросов приводит к:
- Блокировке бэкенда на время всех запросов (каждый занимает 100-500 мс).
- Превышению лимита шлюза — часть запросов вернёт ошибку 429.
- Отсутствию повторных попыток при сбое сети.
Очередь решает все три проблемы: запросы неблокирующие, лимиты соблюдаются, неудачные задачи автоматически повторяются. Rate limiting — механизм, который стоит учитывать на этапе проектирования.
Что входит в работу по интеграции?
- Анализ требований: аудит текущего приложения, выбор шлюза, расчёт бюджета.
- Серверная часть: проектирование очереди (RabbitMQ / Redis), реализация воркеров с throttling, настройка webhook для статусов.
- Мобильный клиент: форма составления сообщения (со счётчиком символов), выбор сегмента получателей, отслеживание прогресса через WebSocket/SSE.
- Тестирование: нагрузочное тестирование до 50 000 сообщений, проверка rate limiting.
- Документация: описание API, схемы, руководство по эксплуатации.
- Поддержка: гарантия 3 месяца, консультации.
Результат — надёжная система рассылки, готовая к масштабированию.
Как отслеживать статусы доставки?
Twilio отправляет webhook на ваш эндпоинт при каждом изменении статуса: queued → sending → sent → delivered или undelivered/failed. Бэкенд агрегирует эти статусы, мобильный клиент запрашивает сводку через эндпоинт:
GET /admin/sms/jobs/{jobId}/stats → { "total": 5000, "sent": 4823, "delivered": 4601, "failed": 177 } Если шлюз не поддерживает webhook (как SMSC на дешёвых тарифах), бэкенд опрашивает статусы по расписанию.
Типичные ошибки при интеграции SMS-рассылки
- Игнорирование rate limiting — приводит к блокировке и потере сообщений.
- Выбор шлюза только по цене — дешёвый шлюз может не иметь webhook-статусов, что усложняет отслеживание.
- Синхронная отправка — зависание бэкенда и превышение лимитов.
- Отсутствие повторных попыток — потеря сообщений при временных сбоях.
Сроки и стоимость
Интеграция шлюза (Twilio или SMSC), реализация очереди, мобильный UI с счётчиком, выбор сегмента и отслеживание прогресса — от 5 до 8 рабочих дней. Стоимость рассчитывается индивидуально в зависимости от сложности и выбранного шлюза. Получите консультацию нашего инженера — он подберёт шлюз под ваш бюджет и нагрузку. Свяжитесь с нами для оценки вашего проекта — мы предложим оптимальное решение под ключ.