Api, webhook или очередь сообщений?
Что выбрать для обмена данными между системами
Когда в компании появляется несколько информационных систем, довольно быстро возникает необходимость заставить их обмениваться данными.
CRM должна передавать заявку в ERP. Сайт — отправлять заказ в учётную систему. Складская система — сообщать о движении товара. Внешний сервис — уведомлять внутреннюю систему об изменении статуса.
На этом этапе часто возникает вопрос: делать API, webhook или очередь сообщений?
Проблема в том, что эти три механизма нередко ставят рядом как будто это три конкурирующих технологии. На практике они решают разные задачи.
«Как одна система может запросить данные или выполнить операцию в другой системе?»
«Как система может сама сообщить другой системе, что что-то произошло?»
«Как передать событие или задачу между системами так, чтобы обработка могла происходить независимо и надёжно?»
И чем сложнее становится архитектура, тем важнее не просто выбрать технологию, а правильно определить характер самого обмена.
Сначала главное: это не три взаимоисключающих варианта
В реальных проектах они очень часто используются одновременно.
Например, интернет-магазин может работать примерно так:
API, webhook и queue здесь не конкурируют. Они выполняют разные функции внутри одного контура.
Именно поэтому вопрос «API или webhook?» иногда поставлен неправильно ещё до начала проектирования.
API: когда системе нужно обратиться к другой системе
API — самый привычный вариант интеграции.
Одна система делает запрос другой:
Например, внутренняя система хочет узнать текущий статус заказа.
Она отправляет запрос: «Дай мне заказ №123».
Вторая система отвечает: «Заказ №123 имеет статус „Отгружен“».
Это естественная модель, когда инициатору действительно нужны данные прямо сейчас.
[ API_USE_CASES ]
- › получения данных;
- › создания объектов;
- › изменения объектов;
- › проверки состояния;
- › выполнения конкретных операций;
- › синхронного взаимодействия между системами.
Например, при открытии карточки клиента интерфейсу действительно может понадобиться получить актуальные данные клиента. Нет большого смысла складывать такой запрос в очередь и ждать, пока какой-то фоновый процесс его обработает.
Но у API есть важное свойство
При обычном синхронном вызове система A зависит от доступности системы B.
Если A делает запрос к B, а B недоступна, A получает ошибку или вынуждена ждать. Для небольшой интеграции это совершенно нормально. Проблемы начинаются, когда через API пытаются построить длинную цепочку зависимостей.
Если каждая операция ждёт следующую, временная проблема одного сервиса начинает распространяться дальше по цепочке. Именно здесь архитектура постепенно начинает требовать других механизмов.
Webhook: когда не нужно постоянно спрашивать «ну что там?»
Webhook работает наоборот.
A → B: А сейчас?
A → B: А теперь?
A → B: А сейчас?
A → B: А теперь?
Допустим, платёжный сервис изменил статус платежа. Вместо того чтобы ваша система каждые несколько минут проверяла, оплачен ли заказ, платёжный сервис может отправить webhook после изменения состояния.
[ ПРИМЕНЕНИЕ WEBHOOK ДЛЯ СОБЫТИЙ ]
- › заказ создан;
- › платёж подтверждён;
- › документ изменён;
- › клиент зарегистрирован;
- › задача завершена;
- › статус доставки изменился;
- › файл готов;
- › операция завершилась.
Webhook фактически является механизмом доставки уведомления о событии через HTTP.
И здесь важно не путать webhook с полноценной очередью сообщений.
Webhook не делает вашу систему автоматически надёжной
Это одна из распространённых ошибок проектирования.
Разработчик принимает webhook через метод POST /webhook и сразу внутри этого HTTP-запроса начинает выполнять тяжелые операции:
- ✕ проверять данные;
- ✕ обращаться к CRM;
- ✕ обращаться к ERP;
- ✕ создавать документы;
- ✕ отправлять письма;
- ✕ обновлять склад;
- ✕ считать какие-то показатели.
На тестовом стенде всё прекрасно.
А потом внешний сервис присылает несколько сотен событий подряд. И внезапно webhook становится не просто уведомлением, а точкой входа для огромного количества работы. Если обработчик работает долго или падает, начинаются повторные доставки, таймауты, дубли и другие неприятные ситуации.
Поэтому хороший webhook-контур часто выглядит иначе:
То есть webhook может быть входом в очередь.
Очередь сообщений: когда системы не должны ждать друг друга
Очередь появляется тогда, когда нам важно разделить момент появления задачи и момент её обработки.
Представим склад. ERP сообщает: «Создано задание на отгрузку». В этот момент совершенно необязательно, чтобы ERP ждала, пока складская система полностью обработает операцию. Можно передать сообщение в очередь:
Теперь системы становятся менее связаны между собой.
ERP сообщает о событии и продолжает свою работу. Потребители получают сообщение и обрабатывают его тогда, когда готовы.
[ QUEUE_BENEFITS ]
- › сообщений много;
- › обработка занимает время;
- › системы работают с разной скоростью;
- › временная недоступность потребителя допустима;
- › нужны повторные попытки;
- › одно событие должны обработать несколько систем;
- › нельзя терять сообщения;
- › нужно сгладить резкие пики нагрузки.
Главное отличие — не в технологии, а в характере взаимодействия
Если сильно упростить:
«Дай данные / выполни операцию»
«У меня произошло событие»
«Вот сообщение, обработай его»
Но одной этой таблицы недостаточно для проектирования. Потому что вопрос обычно не звучит так: «Какую технологию выбрать?»
Он звучит так: «Что должно произойти, если одна система сейчас недоступна?» И вот это уже архитектурный вопрос.
Что будет, если система-получатель недоступна?
Допустим, CRM должна передать заказ в ERP.
└───► ERP недоступна
└───► ERROR
Дальше нужно самостоятельно решать:
- • повторять запрос;
- • сколько раз и через какой интервал;
- • как определить, что операция всё-таки прошла;
- • что делать при таймауте и как избежать двойного создания заказа.
То есть API сам по себе не решает задачу надёжной доставки бизнес-операции.
└───► ERP недоступна
└───► сообщение остаётся в очереди
└───► ERP восстановилась
└───► сообщение обработано
Это уже совершенно другая модель.
Система-получатель может временно отсутствовать, а сообщение не обязательно пропадает вместе с ней.
Но очередь тоже не является волшебной кнопкой
Иногда разработчики после знакомства с брокерами сообщений начинают пытаться отправлять через очередь вообще всё. Это тоже ошибка.
Если пользователю нужно открыть карточку клиента и получить актуальные данные, очередь может быть совершенно неуместна. Пользователь нажал кнопку. Ему нужен ответ сейчас.
Очередь нужна там, где асинхронность действительно является частью задачи.
Что меняется, когда система начинает расти
На маленьком проекте интеграция часто выглядит очень просто: CRM ↔ API ↔ ERP. И это нормально. Не нужно строить распределённую систему из десятка компонентов только потому, что это технически возможно.
Но затем экосистема неизбежно разрастается и появляется:
- › ещё одна CRM;
- › мобильное приложение;
- › склад и сайт;
- › платёжная система;
- › служба доставки;
- › аналитика;
- › документооборот;
- › несколько внешних API.
И постепенно прямые связи начинают хаотично размножаться. Получается классическая топология «спагетти»:
Здесь появляется событийная архитектура
Вместо того чтобы заставлять каждую систему знать обо всех остальных, можно передавать события через общий контур.
Источник сообщает короткий маркер: OrderCreated, а потребители самостоятельно решают, что им делать с этим событием. Это уже значительно более масштабируемая модель.
Но у неё неизбежно появляется собственная инженерная сложность:
- › структура событий;
- › версии сообщений;
- › идемпотентность;
- › порядок событий;
- › повторная доставка;
- › дедупликация;
- › обработка ошибок;
- › мониторинг;
- › dead-letter queue;
- › трассировка операций.
Именно поэтому переход от простого API к очередям — это не просто подключение ещё одного сервиса.
Меняется сама архитектурная модель.
Идемпотентность: слово, которое начинает иметь значение очень быстро
Представим, что система получила сообщение: «Создать документ №123». Обработала его. Но ответ потерялся. Отправитель решил повторить сообщение.
Если обработчик просто выполнит операцию ещё раз, мы получим второй документ.
Поэтому в распределённых системах нужно заранее понимать:
Что произойдёт, если одно и то же сообщение придёт дважды?
Хороший обработчик должен уметь безопасно переживать повторную доставку.
Например, операция может иметь уникальный идентификатор:
Перед обработкой система проверяет по своей базе данных, не выполняла ли она уже это событие.
Это один из тех моментов, которые редко видны в красивой архитектурной схеме, но именно на них потом приходится большая часть реальной инженерной работы.
А если событие пришло не в том порядке?
Ещё один реальный сценарий.
Сначала пришло:
а потом:
Что должна сделать система?
Можно сказать: «Такого не бывает». Но в распределённых системах лучше не рассчитывать на это.
[ ARCHITECTURAL_CHECKLIST ]
- › гарантируется ли порядок сообщений;
- › кем гарантируется;
- › для какого конкретно ключа;
- › что происходит при повторной доставке;
- › может ли сообщение задержаться;
- › что делать с устаревшим состоянием.
Именно здесь простое слово «очередь» превращается в полноценную архитектурную задачу.
Так что же выбирать?
Начинать лучше не с технологии.
Сначала нужно описать сам сценарий обмена.
Если системе нужен ответ прямо сейчас
Смотрите в сторону API.
- • Получить карточку клиента.
- • Проверить наличие товара.
- • Создать заявку.
- • Получить текущий статус.
Если нужно сообщить другой системе о событии
Смотрите в сторону webhook.
- • Платёж подтверждён.
- • Заказ изменил статус.
- • Документ подписан.
- • Новый клиент зарегистрирован.
Если обработку можно отделить от события
Смотрите в сторону очереди сообщений.
- • Обработать 50 000 записей.
- • Передать задания нескольким потребителям.
- • Обработать событие с повторной доставкой.
- • Не останавливать процесс из-за сбоя одной из систем.
На практике чаще всего получается комбинация
Хорошая архитектура редко выглядит радикально.
Она редко строится на утверждениях вроде: «У нас всё на API» или «Мы всё сделали через Kafka». Обычно получается сбалансированная комбинация под разные задачи.
Применяется строго для **синхронных операций**, когда ответ нужен инициатору здесь и сейчас.
Используется для **получения событий** в реальном времени от различных внешних сервисов.
Внедряется для **тяжёлой, фоновой** или критичной к гарантированной доставке обработки данных.
При этом внутри одного и того же сквозного бизнес-сценария они могут последовательно работать вместе:
И это совершенно нормальная архитектура.
Когда не стоит усложнять
Есть ещё одна важная инженерная привычка: не добавлять инфраструктуру раньше времени.
Если у компании две системы, десять операций в минуту и понятный процесс, простого API может быть более чем достаточно. Необязательно сразу внедрять брокер сообщений, десяток микросервисов, event bus и сложную систему мониторинга. Архитектура должна соответствовать нагрузке и требованиям бизнеса.
Сложность тоже имеет стоимость:
- › её нужно разрабатывать;
- › тестировать;
- › мониторить;
- › документировать;
- › обновлять;
- › поддерживать;
- › объяснять новым разработчикам.
Поэтому очередь не является «более взрослым» вариантом API.
Это другой инструмент для другой задачи.
Что мы обычно определяем при проектировании интеграции
Когда проектируем обмен между несколькими системами, недостаточно спросить: «Есть ли у этой системы API?» Мы смотрим глубже:
Кто является источником истины?
Где действительно хранится актуальное состояние объекта?
Who инициирует действие?
Пользователь, внутренняя система или внешний сервис?
Нужен ли ответ немедленно?
Если да — синхронный API часто естественнее.
Что произойдёт при недоступности системы?
Можно ли повторить операцию позже?
Можно ли потерять событие?
Для некоторых данных потеря уведомления неприятна. Для других — критична.
Допустима ли повторная доставка?
Если сообщение придёт дважды, система должна корректно это пережить.
Какой объём и интенсивность обмена?
Десять сообщений в минуту и сто тысяч сообщений в минуту — разные архитектурные задачи.
Сколько систем будет потреблять событие?
Если один источник должен уведомлять пять систем, событийная модель может оказаться естественнее множества вызовов.
Как будет происходить мониторинг?
Нужно видеть не только факт отправки сообщения, но и его дальнейшую судьбу.
Что произойдёт при ошибке?
Повтор, откладывание, ручная обработка, dead-letter queue или другой сценарий должны быть определены заранее.
Самая частая ошибка — выбирать технологию раньше сценария
Можно потратить много времени на выбор конкретного брокера сообщений, настройку webhook и проектирование API, а потом обнаружить, что архитектурная проблема была вообще в другом.
Две системы постоянно спорят о том, какая из них владеет определёнными данными.
Никакой Kafka это не исправит.
Система получает один и тот же заказ из трёх источников и не умеет определить, что это один заказ.
Тут тоже проблема не в API.
Бизнес ожидает, что изменение в одной системе появится в другой мгновенно, хотя вся архитектура построена асинхронно.
Тогда проблема уже в согласовании требований и модели данных.
Поэтому интеграцию лучше начинать не с вопроса: «Какой протокол использовать?»
а с вопроса: «Что именно должно произойти между этими системами и что должно произойти, если что-то пойдёт не по плану?»
Итог
API, webhook и очередь сообщений — не три версии одного и того же инструмента.
- › API хорошо подходит для прямого синхронного запроса или выполнения операции.
- › Webhook удобен, когда система должна сообщить другой системе о произошедшем событии в формате push-уведомления.
- › Очередь сообщений нужна, когда важно полностью отделить отправку события от его обработки, переживать временную недоступность потребителей, распределять пиковые нагрузки или организовать асинхронную обработку.
В простом проекте вполне может хватить API.
В более сложной системе webhook может стать входом в очередь.
А очередь — надежным способом развязать несколько независимых потребителей одного события.
Поэтому правильная архитектура часто выглядит не как выбор одного конкретного протокола, а как осознанное использование каждого механизма там, где он действительно нужен.
И чем больше становится систем, тем важнее не сама технология передачи данных, а то, какие жесткие зависимости между системами вы создаёте этой интеграцией.
Хорошая интеграция — это не просто когда системы технически умеют обмениваться данными.
Хорошая интеграция — когда они могут обмениваться данными предсказуемо, контролируемо и без превращения одной временной ошибки в полную остановку всего процесса.
Почему интеграции между системами ломаются
Почему данные в разных системах расходятся
Как синхронизировать данные между системами
🔒 Данные и доступ к системам заказчика обрабатываются в соответствии с согласованными требованиями к безопасности и конфиденциальности. Условия доступа, хранения и обработки данных определяются архитектурой проекта и договором.
Сайт носит исключительно информационный характер и не является публичной офертой в соответствии со статьёй 437 Гражданского кодекса РФ. Цены, состав и условия предоставления услуг уточняются при проектировании решения и фиксируются в договоре. Условия технического сопровождения и уровень сервиса могут дополнительно определяться отдельным соглашением (SLA).
Автоматизация бизнеса и ИИ-решения под ключ
Самозанятый Скопец Антон Викторович ИНН 741709260870