Чтобы обрабатывать DLR-статусы доставки SMS без риска уронить CRM-систему во время массовых рассылок, откажитесь от синхронного приема вебхуков напрямую в базу данных. Оптимальная схема включает промежуточный легковесный буфер (брокер сообщений или очередь задач) между SMS-шлюзом и вашей CRM. Шлюз отправляет вебхук о смене статуса, сервер-приемник моментально отвечает кодом 200 OK и складывает событие в очередь, а фоновый воркер порционно обновляет карточки клиентов. В этой статье вы узнаете, как шаг за шагом настроить такую связку и сохранить стабильность системы.
Почему прямая отправка DLR в CRM перегружает сервер?
Когда бизнес запускает сервисную или маркетинговую рассылку на несколько тысяч клиентов, ответы от мобильных операторов начинают возвращаться практически одновременно. Отчет о доставке (Delivery Receipt или DLR) генерируется сетью оператора в момент изменения статуса сообщения: отправлено, доставлено абоненту, просрочено или отклонено. Если на каждую смену статуса SMS-шлюз дергает тяжелый эндпоинт CRM, в базе данных возникает лавина блокировок строк и таблиц.
Большинство типовых CRM не рассчитаны на сотни входящих HTTP-запросов в секунду. Каждый такой запрос инициирует авторизацию, поиск сущности по номеру телефона или ID сообщения, проверку триггеров и запись в журнал. При пиковых нагрузках процессор сервера загружается до предела, пул соединений с базой данных исчерпывается, а менеджеры компании теряют возможность нормально открывать сделки и принимать звонки. Чтобы этого избежать, полезно разобрать, как настроить интеграцию CRM и SMPP для SMS-уведомлений с учетом ограничений корпоративного сервера.
Как устроена правильная асинхронная архитектура обработки?
Решение проблемы заключается в разделении двух процессов: быстрого подтверждения приема статуса от шлюза и отложенного обновления данных внутри CRM. Для этого между шлюзом и CRM размещают буферный микросервис.
Схема взаимодействия состоит из трех последовательных шагов:
- Прием вебхука: Минималистичный веб-сервер принимает POST-запрос от провайдера, валидирует входящий payload (ID сообщения, статус, время события) и без обращения к основной базе сразу помещает JSON в очередь. Клиенту мгновенно возвращается ответ HTTP 200 OK.
- Буферизация: В качестве очереди задач используют Redis, RabbitMQ или PostgreSQL с быстрой вставкой. Очередь накапливает тысячи DLR-пакетов, выступая амортизатором при резких всплесках трафика.
- Фоновая обработка (воркеры): Отдельный фоновый скрипт забирает данные из очереди фиксированными пачками (батчами) и обновляет статусы в CRM с той скоростью, с которой система способна их переварить без задержек для пользователей.
Если бизнес отправляет сервисные оповещения, например в сфере услуг, такой подход гарантирует непрерывность рабочих процессов. О том, как это работает на практике, мы подробно описывали в материале про то, как настроить SMPP-шлюз для статусов ремонта с DLR.
Сравнение методов получения статусов доставки
Выбор способа передачи DLR зависит от объема рассылок и архитектуры вашего программного обеспечения. В таблице ниже сопоставлены три основных подхода к синхронизации статусов.
| Метод интеграции | Нагрузка на CRM | Сложность настройки | Скорость обновления | Устойчивость к сбоям |
|---|---|---|---|---|
| Периодический опрос (Polling через REST API) | Высокая постоянная нагрузка | Низкая | Медленно (задержка до нескольких минут) | Средняя |
| Прямой вебхук в CRM без буфера | Критические пиковые перегрузки | Средняя | Мгновенно | Низкая (риск потери части пакетов) |
| Асинхронные вебхуки через очередь задач | Равномерная контролируемая нагрузка | Средняя | Секунды (по мере разбора очереди) | Высокая |
На какие параметры шлюза и сессии обратить внимание?
При настройке шлюза важно учитывать пропускную способность соединения (TPS — Transactions Per Second) и размер окна передачи (window size). Протокол SMPP версии 3.4 работает поверх TCP и позволяет отправлять сообщения и получать статусы в асинхронном режиме в рамках одной сессии (Хабр, 2024). Техническая команда со стороны провайдера контролирует состояние сессии, время ответа и отказы, сопоставляя принятые сообщения с итоговыми статусами доставки (Altcraft, 2024).
Если ваш транспортный уровень упирается в лимиты HTTP-запросов, переход на бинарный протокол обеспечивает более стабильное управление потоком данных (QUICKTEL, 2024). Для отправки цепочек триггерных сообщений важно заранее согласовать с поставщиком достаточный TPS, чтобы DLR-отчеты возвращались без искусственных задержек на стороне операторских шлюзов. Подробнее об этом читайте в руководстве о том, как настроить SMS-цепочку через SMPP для малого бизнеса.
Типичные ошибки при обработке DLR-отчетов
Даже при использовании очередей инженеры нередко допускают архитектурные просчеты, которые приводят к рассинхронизации статусов или зависанию воркеров:
- Отсутствие идемпотентности обработчика: Оператор или шлюз могут повторно отправить один и тот же статус DLR из-за сетевого таймаута. Если обработчик не проверяет, был ли этот статус уже записан, в CRM могут повторно сработать триггерные действия.
- Блокировка потока долгим ответом вебхука: Если приемник вебхука тратит более 1–2 секунд на ответ, шлюз считает запрос неудавшимся и начинает повторять отправку, создавая лавинообразную перегрузку.
- Игнорирование промежуточных статусов: Сообщение проходит несколько состояний (ENROUTE, DELIVRD, EXPIRED, UNDELIV). Если перезаписывать финальный статус более ранним из-за рассинхронизации очереди по времени, данные в CRM станут неверными.
- Отсутствие механизма Dead Letter Queue (DLQ): Ошибочные пакеты с поврежденным телом запроса не должны блокировать всю очередь; их необходимо перемещать в отдельный список для ручного анализа.
3 шага, которые стоит сделать для запуска асинхронной обработки DLR:
- Создать отдельный легковесный эндпоинт, который валидирует входящие вебхуки от SMS-шлюза и сразу возвращает статус 200 OK.
- Подключить Redis или RabbitMQ для временного хранения входящих DLR-пакетов в виде очереди задач.
- Настроить фоновый воркер, который считывает события пачками по 50–100 записей и обновляет базу данных CRM с фиксированным интервалом.
