---
title: "Очереди и события: что происходит, когда получатель лёг"
url: "https://kzsaleshub.com/ocheredi-i-sobytiya-dlya-prodavca/"
type: "knowledge_article"
category: "Продукт"
language: "ru"
source: "KZSalesHub"
published: "2026-10-13"
last_updated: "2026-09-30"
---

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

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

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

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

**[Асинхронно, через очередь](https://kzsaleshub.com/glossary/ochered-soobshchenij/).** Отправитель кладёт сообщение в очередь и продолжает работу. Получатель забирает, когда может. Если получатель лежит, сообщения ждут; когда поднимется — разберёт накопленное. Система не падает, а отстаёт, и это принципиально другое качество.

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

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

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

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

[Событийная модель устроена иначе](https://kzsaleshub.com/glossary/sobytijnaya-arhitektura/): система сообщает факт — «заказ оформлен» — и не знает, кого это интересует. Подписчиков может быть один, а может пять: склад, бухгалтерия, аналитика, рассылка, программа лояльности. Новый подписчик добавляется без изменения того, кто сообщает.

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

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

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

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

**[Повторы.](https://kzsaleshub.com/glossary/idempotentnost/)** Большинство систем гарантируют доставку «хотя бы один раз», а не «ровно один раз». Значит, одно и то же сообщение может прийти дважды, и получатель обязан уметь это распознавать. Отсюда классическая история про задвоенные начисления и списания.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

### Что забрать с собой

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

**Как объяснить разницу нетехническому руководителю?**

Через почту и телефонный звонок. Звонок требует, чтобы собеседник взял трубку прямо сейчас; письмо дойдёт и подождёт, пока он освободится. Оба нужны, но для разных задач — и выбор определяется тем, можно ли ждать.

**Клиент боится, что данные «зависнут в очереди». Что ответить?**

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

**Всегда ли нужна отдельная система очередей?**

Нет. Для небольших объёмов встроенных возможностей базы данных или простого механизма отложенных задач часто достаточно. Продавать промышленную платформу под два обмена в час — способ получить недовольного клиента.

**Что отвечать на «у нас всё работает напрямую и нормально»?**

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

**Как это связано с интеграциями в целом?**

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

---
Источник: https://kzsaleshub.com/ocheredi-i-sobytiya-dlya-prodavca/