Уявіть: ваш бекенд надсилає 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 робочих днів. Вартість розраховується індивідуально залежно від складності та обраного шлюзу. Отримайте консультацію нашого інженера — він підбере шлюз під ваш бюджет та навантаження. Зв'яжіться з нами для оцінки вашого проєкту — ми запропонуємо оптимальне рішення під ключ.