Я выбираю прямой обмен или очередь по цене недоступности, а не по моде

Я выбираю прямой обмен между системами или очередь не по тому, что быстрее звучит на схеме. Для меня главный вопрос другой: что бизнес потеряет, если в момент операции соседняя система недоступна? Если продажа не может быть создана без мгновенного ответа склада, это один разговор. Если заказ можно принять, а подтверждение остатков придёт через минуту, — совсем другой.

На архитектурных схемах прямой запрос выглядит заманчиво: одна система спрашивает другую и сразу получает ответ. Очередь кажется лишним посредником. Но в обычном рабочем дне цена этой простоты быстро проявляется. Один сервис обновляется, второй отвечает медленно, сеть коротко пропадает — и операция клиента внезапно зависит от того, что он никогда не видел.

Два способа договориться

При прямом обмене система А ждёт ответ системы Б прямо сейчас. Это разумно, когда ответ нужен для решения, которое нельзя принять позже: например, проверить право пользователя войти в закрытый раздел или получить актуальную цену перед оплатой. Здесь ожидание — честная часть сценария. Пользователь должен знать, что операция пока не завершена.

При обмене через очередь система А фиксирует событие и передаёт его на обработку отдельно. Система Б получит его чуть позже, а если временно недоступна — сообщение дождётся. Это подходит, когда бизнес допускает небольшую задержку, но не допускает потерю. Например, заявка принята в CRM, а в учётную систему должна попасть надёжно, даже если она обновляется или перезапускается.

Ни один способ не является «современнее» другого. Ошибка начинается, когда их выбирают по привычке. Прямой обмен ставят везде ради простоты разработки, а очередь — везде ради модной надёжности. В итоге либо обычная работа ломается из-за короткого сбоя, либо команда не понимает, почему данные появились не сразу.

Начинаю не с протокола, а с обязательства

Я бы выписал одну операцию обычным языком: «менеджер подтвердил заказ», «клиент оплатил счёт», «мастер закрыл работу». Затем спросил бы четыре вещи.

• Что в этот момент уже обещано клиенту или другому отделу?
• Какой ответ нужен немедленно, а какой можно получить позже?
• Что будет, если соседняя система не отвечает десять минут?
• Как команда узнает, что операция дошла не полностью?

На этих вопросах архитектура обычно становится менее абстрактной. Если без ответа склада нельзя пообещать отгрузку, проверка остатков может быть синхронной. Но письмо клиенту, запись в аналитику или создание задачи на упаковку редко должны заставлять менеджера ждать. Их лучше передать так, чтобы они не пропали при временной недоступности получателя.

Очередь не отменяет ответственность

Иногда очередь воспринимают как коробку, в которую можно положить проблему и забыть. На деле она добавляет несколько обязанностей. Нужно знать, кто владеет сообщением, сколько оно может ждать, что делать после нескольких неудачных попыток и как не обработать одну операцию дважды.

Повторная доставка — не редкая техническая деталь, а нормальная ситуация. Сообщение могло дойти, но подтверждение о его получении потерялось. Поэтому получатель должен уметь сказать: «эту операцию я уже видел» — и не создать второй заказ или второе списание. В статье о повторной отправке операции я подробно разбирал этот принцип: надёжность не равна единственной попытке.

Ещё важнее понятный статус для бизнеса. Не «в брокере сообщение с идентификатором», а «заказ принят, данные для склада будут переданы; сейчас есть задержка». Техническая команда должна видеть причину, а менеджер — следующий шаг и последствия для клиента. Если эти два представления не связаны, очередь лишь переносит неопределённость из одного интерфейса в другой.

Прямой вызов тоже нуждается в границах

У синхронного обмена есть собственная ловушка: цепочка зависимостей. Сайт ждёт CRM, CRM ждёт учётную систему, та ждёт сервис доставки. Одна заминка в конце делает медленной всю цепочку. Пользователь видит «крутящийся» экран, а команда начинает искать проблему сразу в четырёх местах.

Поэтому прямой вызов должен быть коротким, с понятным тайм-аутом и запасным сценарием. Если проверка не успела завершиться, система не должна бесконечно ждать. Она либо честно просит повторить действие, либо принимает операцию в безопасное промежуточное состояние. Какое именно — решает не разработчик в одиночку, а владелец бизнес-правила.

Полезно также не смешивать проверку и доставку. Проверить, разрешено ли действие, иногда нужно прямо сейчас. Передать историю действия в соседнюю систему можно позже. Когда эти два смысла склеены в один API-вызов, интеграция становится хрупкой без видимой причины.

Важен порядок, а не только факт доставки

Очередь особенно полезна, когда сообщение не должно пропасть. Но это ещё не означает, что оно придёт в нужном порядке. Если сначала ушло «заказ создан», а затем «заказ отменён», получатель не должен случайно увидеть их наоборот и вернуть отменённый заказ к жизни. Для одних процессов это несущественно, для других — критично.

Здесь помогает не магия платформы, а простая модель данных: у операции есть устойчивый идентификатор, понятная версия или последовательность, а получатель умеет отклонить устаревшее действие. Если бизнес допускает обработку в любом порядке, это тоже нужно назвать. Например, уведомление клиенту может прийти немного позже, а изменение остатка — нет. Разная цена ошибки требует разных правил.

Я бы обязательно договорился и о сроке жизни сообщения. Если заказ три дня ждёт обработчика, это уже не «повторим позднее», а отдельная ситуация для владельца процесса. Очередь не должна быть архивом неопределённости. Ей нужен предел ожидания и понятный маршрут для операций, которые не удалось завершить автоматически.

Что показать сотруднику, пока данные едут

Асинхронность раздражает не сама по себе, а когда она невидима. Сотрудник нажал кнопку и не понимает: действие принято, не принято или система зависла. Поэтому результат стоит назвать человеческим языком. «Заявка зарегистрирована, документ готовится», «изменение передано на обработку», «нужна повторная проверка» — это не украшение интерфейса, а часть архитектуры.

Тогда человек не начинает нажимать кнопку второй раз и не создаёт дубликаты. А команда получает сигнал, что пора посмотреть на конкретную операцию. Этот же принцип работает и при прямом обмене: если система ждёт ответ, пользователь должен видеть, чего именно она ждёт и что произойдёт, если ответ не придёт.

Как проверить выбор до большого запуска

Я не начинаю с нагрузки в тысячи сообщений. Сначала беру одну критичную операцию и прохожу её в трёх неудобных условиях: получатель отвечает медленно, получатель недоступен, подтверждение потерялось после обработки. Для каждого случая нужно увидеть не только технический лог, но и то, что происходит с клиентом, сотрудником и очередью задач.

Если команда не может проследить один заказ от начала до конца, спор о способе обмена пока преждевременен. Наблюдаемость — это не россыпь графиков. Это способность ответить: где сейчас операция, кто за неё отвечает и какое действие вернёт её в работу. Этот подход хорошо дополняет разбор пути одной операции через интеграцию.

Выбор становится проще

Я выбираю прямой обмен, когда бизнес не может принять решение без ответа сейчас и готов честно показать ожидание пользователю. Я выбираю очередь, когда важнее не потерять действие, а небольшая задержка допустима. Нередко в одном процессе нужны оба подхода: синхронно проверить условие, а асинхронно передать последствия.

Самое опасное — обещать мгновенность там, где система на самом деле не может её гарантировать. Лучше назвать состояние честно, сохранить операцию надёжно и показать команде, что делать дальше. Тогда архитектура перестаёт быть спором между «быстро» и «сложно». Она становится способом защитить конкретное обязательство бизнеса от вполне обычной недоступности соседней системы.