Почему «простая» автоматизация KeyCRM ломает нервы на первой сотне заказов

Я занимаюсь интеграциями систем автоматизации больше пяти лет. За это время я усвоил одно железное правило: любой «простой» вебхук — это мина замедленного действия. На бумаге всё выглядит красиво. Вы настраиваете правила, CRM отправляет JSON на ваш сервер, робот шлет сообщение в мессенджер. Красота.

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

Помню прошлый ноябрь. Черная пятница у нашего клиента, крупного интернет-магазина обуви. Настроена стандартная keycrm автоматизация через простенький скрипт на Node.js, который перекидывал новые заказы в рабочий чат Telegram. Клиент доволен, мы закрыли задачу за пару часов. И тут пошел трафик. Примерно на 140-м заказе за час начался ад.

В чат Telegram посыпались дубли. Одно и то же уведомление о покупке кроссовок прилетало по пять-шесть раз. Менеджеры начали путаться, звонить одним и тем же покупателям дважды, подтверждать уже отправленные заказы. Полный хаос на ровном месте. Что произошло?

Анатомия вебхук-шторма

Дело в природе вебхуков KeyCRM. Когда в CRM создается заказ или меняется его статус, система отправляет HTTP-запрос на ваш обработчик. Она ждет ответа. Быстрого ответа. Если ваш скрипт или принимающий сервис задумался хотя бы на 2-3 секунды (например, из-за медленного ответа стороннего API), KeyCRM считает, что доставка сорвалась.

Что делает нормальная CRM в таком случае? Пробует отправить данные еще раз. Это называется ретраями (retries). В итоге, пока ваш первый поток медленно записывал данные и пытался достучаться до серверов мессенджера, KeyCRM уже отправила второй, третий и четвертый вебхук с тем же самым ID заказа. Скрипт принял их все и выдал в чат пачку одинаковых сообщений. А если в этот момент у самого Telegram случился секундный затык, лавина дублей становится неконтролируемой.

Как построить надежный мост

Чтобы автоматизация не падала от легкого дуновения ветра, ее нельзя собирать на коленке. Вы не имеете права обрабатывать вебхук «на лету» в том же потоке, который его принял.

Первое правило надежного коннектора — мгновенный ответ. Ваш сервер должен принять JSON от CRM, сказать ей «200 OK» (я всё получил, спасибо) быстрее, чем за 100 миллисекунд, и положить задачу в очередь. Только после этого запускается фоновая обработка.

Второе правило — обязательная дедупликация. Нужен быстрый кэш, где каждый входящий ID заказа блокируется на 30–60 секунд. Прилетел дублирующий вебхук? Мы видим блокировку в кэше и просто игнорируем его, не плодя спам в рабочих чатах.

Третье правило — валидация «грязных» данных. Менеджеры в CRM — живые люди. Они могут случайно стереть номер телефона, вставить смайлик в поле цены или оставить обязательное поле пустым. Если ваш обработчик ожидает строго определенный формат данных и спотыкается на пустом поле, вся цепочка падает. Хороший коннектор должен уметь переваривать любой мусор, заменять пустоту на дефолтные значения и не падать в обморок от некорректного JSON.

Мы в GuardLabs наступили на эти грабли достаточно раз, чтобы перестать верить в простые решения из коробки. Если вам надоело ловить дубли, чинить отваливающиеся скрипты и слушать жалобы менеджеров на пропущенные заказы, у нас есть готовое решение. Мы создали надежный Мост между вебхуком KeyCRM и Telegram, который берет на себя всю грязную работу по валидации, дедупликации и гарантированной доставке сообщений без сбоев под любой нагрузкой.