Прямой ответ
Event-driven архитектура (EDA) — сервисы общаются событиями через брокер (не синхронными вызовами — «заказ создан» публикуется, заинтересованные реагируют асинхронно — микросервисы — развязка во времени и пространстве); три уровня событийности (по нарастанию связности данных — классификация Фаулера): (1) event notification (минимальный — «произошло X, id=123» — получатель сам запрашивает детали — лёгкий payload, но получатель ходит обратно к источнику — скрытая синхронная связь — «асинхронно, но связан»); (2) event-carried state transfer (событие несёт состояние — «заказ создан: {id, items, total, status}» — получатель обновляет свою копию — не ходит к источнику — истинная развязка — но дублирование данных — согласованность eventually — CQRS-контекст); (3) event sourcing (состояние = поток событий — отдельная тема — event sourcing — максимальная событийность — максимальная сложность); выбор уровня — по потребности в развязке против цены дублирования — «notification для триггеров, state transfer для независимости» — дизайн; координация — два паттерна: хореография (сервисы реагируют на события без центрального координатора — «заказ создан → оплата → доставка → уведомление» — цепочка событий — простая для 2–4 шагов, но «кто за что отвечает» размывается — сложность отладки растёт с длиной цепочки — observability); оркестрация (центральный сага-координатор управляет потоком — saga — «дирижёр знает весь процесс» — явнее/отлаживаемее для длинных бизнес-процессов — шаг → событие → следующий шаг — компенсирующие действия явные); критерий: короткая линейная цепочка — хореография, длинный процесс с компенсациями/ветвлениями — оркестрация — паттерн-выбор; гарантии доставки (ядро надёжности EDA): брокер даёт at-least-once (повторы — идемпотентность обязательна — «событие обработано дважды» — норма, не баг — идемпотентный ключ — Kafka-семантика), at-most-once (потери — редко приемлемо), exactly-once (внутри брокера — но граница с БД — outbox/идемпотентность — saga); outbox-паттерн (главный для корректности): «изменил БД + опубликовал событие» не атомарно (БД закоммичена, публикация упала — событие потеряно; опубликовано, БД откатилась — фантомное событие) — outbox: событие пишется в таблицу в той же транзакции, отдельный процесс читает и публикует — saga/outbox — атомарность «данные+событие» — обязательный паттерн для надёжной EDA; цена EDA (честно): eventual consistency (состояние расходится на секунды — «баланс в двух сервисах разный» — бизнес должен терпеть — CAP-контекст), сложность отладки (поток через N сервисов — трейсинг обязателен — трейсинг — «где моё событие» — без трейсов — тьма), операционная нагрузка (брокер — критический компонент — надёжность — failover); когда EDA не нужна: синхронный ответ нужен немедленно (API «создать заказ» — ответ сразу — синхронный вызов честнее), 2–3 сервиса с простой логикой (EDA оверхед без выгоды — монолит проще — монолит-выбор), команда без опыта распределённости (EDA требует зрелости — техдолг — «событийность ради моды» — антипаттерн).
Практика: схемы событий и эволюция
Схема события (контракт — критично для эволюции): структура (event_type, version, occurred_at, aggregate_id, payload — структура — единый конверт — маршрутизация/отладка), версионирование (v1/v2 — обратная совместимость — новые поля опциональны — старые потребители не ломаются — API-версии — «изменил схему события — сломал 5 потребителей» — классика); schema registry (Confluent/Avro/Protobuf — контроль совместимости — «схема несовместима — публикация отклонена» — контракты — эволюция под контролем — gRPC-схемы); порядок и партиционирование: события одного агрегата — в одну партицию (порядок по ключу — Kafka — «заказ обновлён до создания» — порядок нарушен — состояние сломано — ключ партиционирования = aggregate_id); дубликаты и идемпотентность: обработчик хранит processed_event_ids (unique — повтор — no-op — идемпотентность — at-least-once требует); мертвые письма (ядовитое событие — 3 ретрая → DLQ — партиция не блокируется — вебхук — разбор DLQ — incident); компенсирующие события (сага-откат — «оплата не прошла → заказ отменён» — saga — обратные события — не «удалить», а «компенсировать» — event sourcing-логика); event notification vs state на практике: notification — триггеры (отправить email, обновить кэш — получатель запросит детали), state transfer — реплики данных (поисковый индекс, дашборд-проекции — получатель автономен — CQRS).
Практический сценарий: монолит → события без хаоса
Контекст: e-commerce монолит (заказы/оплата/доставка/уведомления в одном коде), боль: релиз одного модуля требует деплоя всего, «уведомления тормозят оформление заказа» (синхронно в одном процессе); цель: выделить уведомления и доставку в события, заказы/оплату оставить синхронными (осознанный выбор — не «всё в события» — микросервисы-антипаттерны); шаги: (1) аудит связей (что реально асинхронно — уведомления/доставка/аналитика — синхронно — оплата (ответ нужен сразу) — дизайн); (2) outbox в монолите (таблица outbox в БД заказов — событие «OrderPlaced» пишется в транзакции заказа — saga — отдельный диспатчер публикует в Kafka (Kafka — атомарность «заказ+событие» — фантомные/потерянные события исключены); (3) event-carried state (событие несёт {order_id, items, total, customer_email} — сервисы уведомлений/доставки не ходят в монолит — автономны — CQRS-паттерн); (4) хореография для короткой цепочки (OrderPlaced → notification-service + delivery-service независимо — 2 потребителя — просто — без оркестратора — паттерн-выбор); (5) идемпотентность (notification хранит processed order_id — дубль события — одно письмо — идемпотентность — at-least-once Kafka учтён — Kafka); (6) отладка (trace_id из заказа → события → потребители — OTel — «где моё уведомление» — трейс — трейсинг); (7) DLQ + мониторинг (ядовитые события, lag потребителей (consumer-лаг — алерты); результат: деплой уведомлений независим (релизы чаще — деплой), оформление заказа ускорилось (уведомления асинхронны — не блокируют — p95 −200 мс — SLO), но появились новые заботы: eventual consistency (заказ создан, уведомление через 2 с — «где моё письмо» — UX-ожидания настроены), отладка сложнее (трейсинг стал обязательным — observability), DLQ-разбор (рутина — incident); вывод: EDA решили конкретную проблему (асинхронность уведомлений + независимость деплоя), не «перевели всё на события» — оплата осталась синхронной (ответ нужен сразу) — событийность как инструмент, не религия — техдолг — граница синхронное/асинхронное — архитектурное решение с критериями — ADR.
FAQ
Хореография или оркестрация — как выбрать? Хореография: сервисы реагируют на события децентрализованно (нет координатора — «каждый знает свою реакцию» — простая для коротких линейных цепочек (2–4 шага — сценарий выше), минусы: поток неявный («кто что делает» в голове/коде, не в одном месте — отладка через трейсинг — observability), с ростом длины — «распределённый монолит» (цепочка A→B→C→D→E — связь хуже синхронной — микросервисы-антипаттерн); оркестрация: центральный координатор (сага-оркестратор — saga — «процесс в одном месте» — явные шаги/компенсации/ветвления — для длинных бизнес-процессов (оформление заказа с оплатой/доставкой/отменой), минусы: оркестратор — точка концентрации (но не single point of failure при правильном деплое — failover); критерий: короткий линейный поток → хореография, длинный с ветвлениями/компенсациями → оркестрация — паттерн; гибрид (часть хореография, часть оркестрация — нормально — не догма — дизайн).
Как гарантировать, что событие не потеряется при публикации? Проблема: «БД-транзакция + публикация» не атомарны (две системы — распределённость); решения: outbox (событие в таблицу в транзакции БД → диспатчер публикует — атомарность на уровне БД — saga/outbox — главный паттерн — сценарий выше), транзакционный продюсер Kafka (атомарность «данные Kafka + offset» — но не внешняя БД — Kafka-EOS), 2PC (распределённая транзакция — сложно/медленно/хрупко — редко оправдан — saga-предпочтительнее); outbox-детали: диспатчер читает outbox (poll/CDC — Debezium — логическая репликация), публикует, помечает published, идемпотентная публикация (event_id — дубль — no-op — идемпотентность), outbox-таблица чистится (published-строки — TTL/архив — vacuum-контекст); «просто публикуем в try/catch» — недостаточно (catch не спасает от «БД закоммичена, процесс умер до публикации» — outbox закрывает — надёжность).
Event-driven против синхронных вызовов — когда что? Синхронные (REST/gRPC — gRPC): ответ нужен немедленно (API «создать заказ» — клиент ждёт результат — REST), простая логика 2–3 сервисов (EDA оверхед без выгоды), сильная консистентность нужна (баланс/платёж — «актуально сейчас» — eventually не подходит — CAP); событийные: асинхронные реакции (уведомления/аналитика/индексы — ответ не нужен — сценарий выше), развязка сервисов (издатель не знает потребителей — новые потребители без изменения издателя — микросервисы), пиковые нагрузки (брокер буферизует — потребитель догоняет — backpressure), аудит/история (event sourcing — паттерн); гибрид — норма (синхронное ядро + событийная периферия — сценарий выше — «всё или ничего» — ложная дихотомия — дизайн); критерий: «нужен ли ответ сейчас» + «терпима ли задержка» + «нужна ли развязка» — три вопроса — ADR.
Как тестировать event-driven систему? Слои: unit обработчиков (событие-фикстура → обработчик → результат/побочные эффекты — мок — «обработчик OrderPlaced шлёт уведомление» — pytest); интеграционные (реальный брокер в testcontainers — testcontainers — outbox → публикация → потребление — атомарность/доставка проверена — «событие дошло» — не мок); контрактные (схема события — producer/consumer contract — контракты — «издатель изменил схему — потребитель сломан» — тест ловит — версии); E2E-сценарии (полный поток — заказ → оплата → доставка — с компенсациями — saga — «отмена заказа компенсирует доставку» — проверка); идемпотентность (дубль события → один эффект — идемпотентность — негативный тест обязателен); chaos (убить потребителя/брокер под нагрузкой — доставка восстановлена — chaos — надёжность); «EDA не тестируется» — миф — брокер в testcontainers делает потоки тестируемыми — тест-культура — распределённость — не оправдание для отсутствия тестов — техдолг.
Источники: Martin Fowler (event-driven), microservices.io patterns, EIP — ссылки в шапке.