Клиент недавно пришёл с жалобой, которая на первый взгляд казалась мелочью: пару раз в неделю на складе «терялся» заказ. Менеджер находит его в CRM без проблем, а на складе никто не видел. Разобрались быстро — интеграция между магазином и складской системой падала на несколько часов каждую ночь, а ошибка просто оседала в логах, которые никто не читал.
История типичная. По документации API-интеграция выглядит просто: вот эндпоинт, вот токен, вот пример запроса. Проблемы начинаются не в момент подключения, а через месяц-два эксплуатации — когда обе системы живут своей жизнью, и одна из них периодически падает, тормозит или отдаёт что-то неожиданное.
Webhooks или опрос: выбор не такой очевидный
Первое решение при любой интеграции — как одна система узнаёт об изменениях в другой. По сути вариантов два: ждать, пока внешняя система сама пришлёт событие (webhook), или периодически спрашивать самому, что изменилось (polling).
Webhook выглядит элегантнее: событие произошло — прилетел запрос, обработали, всё почти мгновенно. Но здесь есть нюанс: webhook сработает, только если принимающая сторона доступна именно в момент отправки. Сервер лёг на минуту ради деплоя — и событие, которое прилетело именно в эту минуту, просто потерялось. Большинство систем не повторяют отправку бесконечно, максимум пару раз.
Опрос, наоборот, некрасивый, зато предсказуемый. Запрос раз в пять минут «дай всё, что изменилось с такого-то времени» всегда догонит пропущенные изменения — следующий запрос подхватит то, что не успел предыдущий. Цена — задержка и нагрузка на обе системы, особенно на большом каталоге.
На практике рабочей схемой чаще оказывается комбинация: webhook для быстрой реакции плюс регулярная сверка раз в час или раз в сутки, которая ловит то, что webhook мог потерять. Кажется избыточным. На деле это страховка на несколько строк кода, которая спасает как раз от истории, с которой началась эта статья.
Почему один и тот же запрос не должен создавать два заказа
Сеть ненадёжна по определению. Запрос ушёл, сервер его обработал, заказ создался в CRM — а ответ до магазина не дошёл из-за таймаута. Магазин видит ошибку и, следуя логике retry, отправляет тот же запрос повторно. CRM получает второй запрос и, если ничего специально не предусмотрено, создаёт второй заказ. Клиенту звонят дважды, склад списывает товар дважды, бухгалтерия путается в отчётах.
Решение называется идемпотентность, и оно довольно простое: каждому запросу, который что-то меняет (создаёт заказ, списывает товар, обновляет баланс), присваивается уникальный идемпотентный ключ. CRM перед обработкой проверяет — этот ключ уже приходил? Если да, возвращает результат прошлой обработки, ничего не создавая заново. Если нет — обрабатывает и запоминает ключ.
Ключ должен генерироваться один раз, на этапе формирования заказа, а не на этапе каждой попытки отправки. Иначе retry просто сгенерирует новый ключ, и проблема вернётся в том же виде.
Retry — это не просто «попробовать ещё раз»
Наивный retry, когда после ошибки система сразу же повторяет запрос, на первый взгляд кажется разумным решением. На деле он способен положить и без того перегруженный сервер: тот отвечает медленнее, получает ещё один запрос, отвечает ещё медленнее — и за пару минут очередь запросов растёт лавинообразно.
Рабочий подход — экспоненциальная задержка между попытками: первая повторная попытка через секунду, следующая через две, потом четыре, восемь и так далее, с разумным потолком и небольшим случайным разбросом (jitter), чтобы сотни клиентов не били по серверу ровно в одну секунду.
Отдельный вопрос — что делать, когда попытки закончились, а результата нет. Здесь появляется dead-letter queue, очередь непригодных сообщений: вместо того чтобы просто потерять событие после пятой неудачной попытки, его откладывают в отдельную очередь для ручного разбора. Кто-то из команды раз в день просматривает эту очередь и решает — повторить, пропустить или разобраться вручную. Без такой очереди событие просто исчезает, и о пропущенном заказе вы узнаёте от клиента, а не от системы.
Кто главный, когда данные расходятся
Представим: клиент поменял номер телефона в CRM во время звонка менеджеру. Через час тот же клиент поменял телефон у себя в личном кабинете на сайте. Какое значение правильное?
Без чёткого правила ответ зависит от того, какая синхронизация отработала последней — а это случайность, не логика. Поэтому ещё до написания кода стоит прямо определить: какая система является источником правды для каких данных. Чаще всего расклад такой — CRM главная для статуса заказа и истории общения с клиентом, магазин главный для каталога и цен, склад главный для остатков. Клиентские данные вроде телефона или адреса — самая спорная зона, и тут нужно явно решить: побеждает последняя по времени запись, или одна из сторон вообще не принимает изменения с другой.
Это решение не техническое, а организационное. Разработчик реализует любую логику, но кто главный — должен определить тот, кто понимает бизнес-процесс: вправе ли сайт «молча» переписать то, что менеджер только что ввёл руками во время разговора с клиентом.
Как понять, что синхронизация тихо сломалась
Худший сценарий — не тот, когда интеграция падает с громкой ошибкой. Худший — когда она продолжает «работать», просто ничего не делая: эндпоинт возвращает 200 OK, очередь обрабатывается, а данные на самом деле уже несколько дней не обновляются, потому что изменился формат ответа на стороне поставщика, протух токен, или кто-то случайно поменял URL.
С этим мы регулярно сталкиваемся на аудитах: клиент уверен, что интеграция работает, потому что «ошибок никто не видел» — а на деле остатки на сайте не обновлялись три недели.
- Счётчик времени последней успешной синхронизации — и алерт, если он старше ожидаемого интервала.
- Мониторинг не только ошибок, но и «подозрительной тишины»: резкое падение числа обработанных событий — тоже сигнал.
- Периодическая сверка контрольных цифр: сколько заказов в магазине за сутки и сколько за тот же период пришло в CRM.
Ни одна из этих вещей не сложна технически. Сложность в том, чтобы кто-то вообще подумал об этом до того, как интеграция ушла в продакшн, а не после третьей жалобы клиента на потерянный заказ.
В итоге
Интеграция, которая технически «работает» в день запуска, и интеграция, которая выдерживает год реальной нагрузки, — это разные уровни работы. Разница не в количестве подключённых эндпоинтов, а в том, что произойдёт, когда один из них на минуту станет недоступен, два запроса придут одновременно, или кто-то на другой стороне поменяет формат данных без предупреждения. Если эти сценарии продуманы заранее, интеграция просто работает годами — тихо и незаметно, что, собственно, и есть цель.
