Очереди и события: что происходит, когда получатель лёг

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

Два способа связать системы и одна принципиальная разница

Синхронно. Отправитель обращается к получателю и ждёт ответа. Просто, понятно, мгновенно. Но пока получатель думает, отправитель стоит; а если получатель лежит, отправитель тоже перестаёт работать. Зависимость передаётся по цепочке: упала одна система из пяти — встали все.

Асинхронно, через очередь. Отправитель кладёт сообщение в очередь и продолжает работу. Получатель забирает, когда может. Если получатель лежит, сообщения ждут; когда поднимется — разберёт накопленное. Система не падает, а отстаёт, и это принципиально другое качество.

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

Вопрос, после которого архитектура обсуждается всерьёз: «Если система-получатель сейчас недоступна, заказ теряется, отклоняется или ждёт?» Три ответа — три разные схемы и три разные цены. Клиенты обычно не задумывались, а последствия у всех трёх разные.

Что такое «событие» и почему это меняет разговор

Обычная интеграция устроена как поручение: «создай клиента в учётной системе». Отправитель знает получателя и знает, что тому делать. Добавили третью систему — переписали отправителя.

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

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

Обратная сторона — честно: за гибкость платят сложностью разбора. Когда что-то не сработало, ответ на вопрос «где именно» требует инструментов и дисциплины, иначе поиск превращается в блуждание.

Три ловушки, о которых не говорят на демо

Порядок. Сообщения могут прийти не в том порядке, в котором отправлялись. «Заказ отменён» способно обогнать «заказ создан», и получатель отменит то, чего ещё нет. Решается, но требует решения — само не рассасывается.

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

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

Где вендоры преувеличивают

«Гарантированная доставка». Гарантируется доставка в очередь и из очереди. Что сообщение будет правильно обработано на той стороне, не гарантирует никто. Формулировка «не потеряется» и «сработает» — разные обещания.

«Реальное время». Как правило, секунды. Для складского учёта отлично, для торгового терминала — нет. Стоит называть числом, а не словом.

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

«Не нужно менять приложения». Нужно. Как минимум научить их распознавать повторы и корректно вести себя при отставании. Это работа разработчиков клиента, и её лучше назвать в смете, а не обнаружить в середине проекта.

Что спросить у своего инженера перед встречей

1. Какие сценарии клиента требуют мгновенного ответа, а какие спокойно переживут задержку в секунды или минуты?
2. Как мы защищаем от повторной обработки одного и того же сообщения?
3. Что происходит при переполнении очереди и кто об этом узнаёт?
4. Есть ли отдельное место для сообщений, которые не удалось обработать, и кто их разбирает?
5. Нужна ли клиенту очередь вообще или для двух систем достаточно прямого обмена?

Красные флаги на стороне клиента

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

Вопросы, которые задаст технический директор

«Что с порядком сообщений?» — вопрос-маркер: его задаёт тот, кто уже обжигался. Ответ должен быть конкретным, а не «обычно порядок сохраняется».

«Как мы повторим обработку за вчерашний день?» — про возможность переиграть события. Ценная и не всегда доступная возможность.

«Сколько сообщений в секунду мы выдержим и где предел?» — про запас прочности. Числа лучше уверенности.

«Кто дежурит по очередям?» — про эксплуатацию. Слой, который никто не смотрит, ломается тихо.