Классическая ситуация: в одном запросе надо сохранить заказ в БД и отправить OrderCreated в Kafka. Выглядит элементарно:
orderRepository.save(order);
kafkaTemplate.send("orders", event); // 💥
Но это dual write — два независимых внешних действия без общей транзакции. И любой сбой ломает консистентность:
▪️ БД закоммитилась, приложение упало до отправки → событие потеряно, соседние сервисы не узнали о заказе
▪️ Событие ушло, а транзакция откатилась → фантомное событие про заказ, которого нет
▪️ Распределённые транзакции (2PC/XA) тут — дорога в ад: медленно, хрупко, Kafka их толком не тянет.
📌 Идея паттерна
Не пишем в брокер напрямую. В той же транзакции БД, что и бизнес-данные, кладём событие в табличку outbox:
INSERT INTO orders (...);
INSERT INTO outbox (id, aggregate, type, payload, created_at) (...);
COMMIT;
Обе вставки в одной локальной транзакции → они атомарны. Либо есть и заказ, и событие, либо ничего. Dual write исчезает: остаётся один источник правды.
🔍 Кто доставляет в Kafka?
Отдельный процесс — message relay. Два подхода:
1️⃣ Polling Publisher — фоновый воркер периодически читает новые строки из outbox, шлёт в брокер, помечает отправленными (или удаляет). Просто и прозрачно, но есть лаг поллинга и нагрузка на БД.
2️⃣ CDC (Debezium) — читаем не таблицу, а WAL/binlog базы. Debezium ловит инсерты в outbox и стримит почти в реалтайме. Сложнее в инфре, зато без поллинга и лишних запросов.
Outbox превращает ненадёжный dual write в один атомарный коммит + асинхронную доставку. Платите за это дубликатами (лечатся идемпотентностью) и eventual consistency.