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

Для крупного e-commerce это заметно при обновлении остатков, смене статусов заказов и в потоковых офферах. В финтехе — при обработке транзакций, скоринге клиентов и расчетах в реальном времени. Здесь реакция на событие должна быть мгновенной, а зависимость между сервисами — минимальной.

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

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

Пример

Когда пользователь оформляет заказ в интернет-магазине, сервис заказов публикует событие order_created. Kafka сохраняет его в топике, и сразу несколько сервисов — логистики, уведомлений, аналитики — могут независимо считать и обработать это событие.

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

Kafka:

[Order Service] → topic "order_events" → [Delivery] [Analytics] [Notifications]

RabbitMQ:

[Order Service] → queue "notify_user" → [Notification Service]

В проектах уровня e-commerce и финтех именно Kafka показывает себя лучше. Брокер выдерживает высокий объем данных, масштабируется без простоев и сохраняет историю событий.

Далее рассмотрим, как подойти к проектированию потоков событий и закладывать в архитектуру гарантии доставки, чтобы система оставалась предсказуемой.

Проектирование и архитектура событийных потоков

Типовые ошибки, которые я видел при проектировании event-driven интеграций:

Отсутствие обработки дублей при повторной доставке.
Нет фиксирования структуры и версий событий.

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

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

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

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

В зависимости от проекта можно выбрать разные форматы:

JSON - самый читаемый и удобный для интеграций, особенно если нужно быстро смотреть события в логах или отлаживать систему;

XML - когда требуется строгий контракт и валидация схемы, чаще в госсистемах;

Avro - для потоковой обработки и аналитики, где важна скорость передачи и четкая типизация.

Для событий в своих проектах я задаю структуру в JSON Schema — чтобы все сервисы работали с одинаковыми ключами и типами данных. Это помогает командам говорить на одном языке: структура событий едина, поля не трактуются по-разному и при изменениях легко проверить совместимость.

Пример простого события в JSON:

{
  "event": "order_created",
  "version": "1.2",
  "order_id": "123456",
  "timestamp": "2025-10-17T08:45:00Z",
  "user": {
    "id": "987",
    "segment": "premium"
  }
}

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

Артефакты помощи

Для визуализации есть 4 основных инструмента, которые дают представление, как асинхронные системы работают на различных уровнях.

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

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

User Story фиксирует триггеры и ожидаемые результаты. Когда процесс заложен, переходим к уровню пользователя или системы: кто запускает событие, какой результат ожидает и какие сервисы реагируют. Начинает отображаться контекст «что именно считать фактом события».

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

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

Гарантии доставки и устойчивость

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

At most once - «не больше одного раза». Сообщение может потеряться, но никогда не повторится. Подходит для процессов, где потеря не критична, например, для обновления кеша или временных метрик.
At least once - «хотя бы один раз». Сообщение может прийти повторно, но не потеряется. Используется чаще всего. Повторы отлавливаются на уровне бизнес-логики - система проверяет, было ли событие обработано ранее.
Exactly once - «ровно один раз». Самая надежная и самая сложная модель: событие обрабатывается единожды и гарантированно не дублируется. Ее применяют там, где цена ошибки высока.

В большинстве сценариев я использую модель at least once, реже - at most once. Exactly once - единожды в финтех проекте с займами, где расчет скоринга и запись результата происходят в одной транзакции. Важно было, чтобы событие не обрабатывалось дважды.

В этом проекте после сбоя брокера стали приходить повторные сообщения, а рассылки запускались несколько раз подряд. Причина - не проверялись уже обработанные события. Мы добавили хранилище идентификаторов и сделали обработку устойчивой к повтору, чтобы дубли больше не создавались.

Теперь каждому событию система присваивает уникальный ID, по которому определяет, взаимодействовала ли она с ним раньше. Если событие уже выполнялось, система его пропускает, если новое - выполняет и фиксирует как обработанное.

Настройка мониторинга асинхронных интеграций

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

Я обычно использую сочетание BI-инструментов и систем визуализации:

Fine BI и Power BI - для отчетов. Можно видеть, сколько событий обработано, сколько повторов, какие задержки. Отчеты обновляются автоматически, показывают динамику.

Grafana и Kibana - мониторинг в реальном времени. Видны топики Kafka, очереди RabbitMQ, скорость обработки сообщений. Можно настроить алерты: уведомления приходят, если очередь растет, есть ошибки или задержки.

Логирование событий - каждое событие сохраняется с уникальным ID. Это помогает проверять, что событие не обработалось дважды, и восстанавливать состояние после сбоев.

Для оркестрации процессов, завязанных на событиях, - Camunda Modeler и Engine. В Modeler строим цепочки событий. Engine их исполняет: запускает сервисы, ждет внешние события, обрабатывает ответы, решает, какой шаг следующий. Так сразу видно, где процесс завис.

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

Ценность для бизнеса: зачем тратить время на Kafka, если и классическая REST работает

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

На нашем финтех-проекте внедрение event-driven интеграций дало конкретные результаты:

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

Но event-driven интеграции подходят не всегда. Суть в том, что выбор подхода зависит от проекта:

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

В реальных системах часто используют комбинацию подходов, чтобы получать лучшее из обоих миров.

Например, в нашем фарма-проекте при подписании документов ЭЦП и отправке в регистр требовалось мгновенное подтверждение на экране врача и четкая ошибка при отказе. Здесь события не подходят. Ответ нужен сразу, и есть юридические требования к фиксации результата. Мы сделали синхронный REST с проверками и возвратом статуса за один шаг. Event-driven оставили только для последующих уведомлений.

С чего начать, чтобы не утонуть в событиях

Когда вы переходите на event-driven интеграции, легко потеряться в потоке, особенно если проект уже в продакшне. Не нужно переделывать все и сразу. Начинать стоит с малого и понятного, а именно - выбрать один процесс, где события реально помогут, и сделать пилот. Так вы прощупаете пользу и выявите сложные места без риска сломать всю систему.

Определите ключевые события и ответственных

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

Договоритесь о правилах форматов и имен

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

Мониторинг и совместная работа команд

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

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

Какие критерии вы считаете ключевыми при выборе между синхронными и асинхронными интеграциями в своих проектах? Как оцениваете их влияние на бизнес-процессы?

Переход на event-driven интеграции — создаем устойчивую архитектуру с гарантией доставки