Transactional outbox: конец двойной записи между БД и брокером

Размещают заказ. Хендлер делает две вещи: INSERT строки заказа, потом kafka.publish("OrderPlaced"). В счастливом пути месяцами всё ок. Потом ночью у брокера 400ms сбой; вызов publish зависает, и под прибивает OOM прямо посреди вызова. Строка заказа закоммичена и видна — с клиента списали деньги — но OrderPlaced так и не доехал. Fulfillment ничего не узнаёт. Посылка не отправляется. В логах ни одной ошибки, потому что ничего не бросило исключение. Сверка находит это спустя неделю, руками.

Почему у двойной записи нет безопасного порядка

У тебя две системы без общей транзакции: база данных и брокер сообщений. Любой хендлер, который должен обновить одну и уведомить другую, делает двойную запись, и нет такого порядка этих двух вызовов, который переживёт крах в промежутке между ними.

Записать строку, потом опубликовать: крах после коммита, до publish — и ты потерял событие. Состояние изменилось, но downstream об этом не знает. Опубликовать, потом записать строку: крах после publish, до коммита — и у тебя фантомное событие: consumer’ы реагируют на заказ, который откатился и никогда не существовал. Обернуть оба в try/catch и «компенсировать» при сбое — значит написать крошечный багованный координатор распределённых транзакций, который сам может упасть между шагами. Двухфазный коммит (2PC) поверх БД и Kafka закрыл бы промежуток, но Kafka не даёт пригодного для прода XA-участия, а блокирующий координатор 2PC — проблема хуже исходной.

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

Одна транзакция, один источник истины

Паттерн outbox схлопывает двойную запись в одну запись. В той же локальной транзакции БД, которая меняет бизнес-состояние, ты также делаешь INSERT строки в таблицу outbox, описывающей событие. Поскольку обе записи в одной ACID-транзакции против одной базы, они коммитятся вместе или откатываются вместе — атомарно, бесплатно, без координатора.

BEGIN;
  INSERT INTO orders (id, status, ...) VALUES (...);
  INSERT INTO outbox (id, aggregate, type, payload, created_at)
    VALUES (uuid, 'order', 'OrderPlaced', '{...}', now());
COMMIT;

После коммита истина «событие OrderPlaced должно быть доставлено» теперь durable в той же базе, что и сам заказ. Публикация в брокер становится отдельным, ретраябельным шагом, который выполняет relay (он же message relay / dispatcher): читает неотправленные строки outbox и пушит их в Kafka. Работа хендлера закончена на COMMIT; он вообще не разговаривает с брокером. Ты обменял невозможную атомарную двойную запись на тривиально-атомарную одиночную запись плюс асинхронный, краш-безопасный насос.

Два вида relay: polling против чтения лога

Relay читает outbox одним из двух способов, и выбор между ними — это решение сеньора в этом паттерне.

Polling publisher — воркер по интервалу запускает SELECT ... WHERE sent = false ORDER BY created_at LIMIT N, публикует каждую строку, затем помечает её отправленной. Предельно просто, работает на любой базе, без лишней инфраструктуры. Цена: каждый poll — нагрузка на твою основную OLTP-базу, есть работа или нет, а end-to-end latency ограничена твоим интервалом. Интервалы 100ms–1s типичны; уход к 25–50ms ради свежести умножает нагрузку запросами, а при 10–30 репликах relay этот постоянный polling становится реальным бременем для primary.

Change Data Capture (CDC) — вместо запроса к таблице инструмент вроде Debezium читает write-ahead log базы (WAL в Postgres) и эмитит событие в момент, когда INSERT в outbox закоммичен. Latency падает до единиц миллисекунд, нагрузки polling’ом на таблицу нет вовсе, и ты получаешь естественный порядок коммитов из лога. Цена операционная: теперь ты держишь и мониторишь CDC-коннектор, управляешь replication slots и думаешь про удержание WAL. CDC — это то, что подхватывает следующий юнит.

Гарантия — at-least-once, поэтому consumer обязан быть идемпотентным

Outbox закрывает промежуток потери событий, но не даёт exactly-once доставку, и вера в обратное — тот самый failure mode, что кусается в проде. Relay делает две неатомарные вещи: публикует в брокер, затем помечает строку отправленной. Если он падает после того, как брокер принял сообщение, но до коммита UPDATE, строка всё ещё выглядит неотправленной — поэтому при рестарте relay публикует то же событие снова. Ты получаешь at-least-once: каждое событие доставляется один или больше раз.

Значит, контракт для всех downstream нерушим: consumer’ы обязаны быть идемпотентными. Помечай каждую строку outbox стабильным event id, проноси его через брокер, и пусть consumer’ы дедуплицируют по нему — обычно через таблицу inbox обработанных id (хранят от нескольких часов до пары дней) или через уникальный constraint на побочный эффект. Обработка OrderPlaced дважды должна списать с карты один раз. Без идемпотентности outbox не делает систему надёжной; он делает её надёжно дублирующей.

Операционный налог: bloat, порядок и конкурирующие relay

Три вещи рано или поздно поднимут кого-то по тревоге:

• Раздувание таблицы (bloat). Outbox растёт с каждым событием. Отправленные строки надо вычищать, иначе таблица — и её индексы — раздуваются до сотен тысяч строк, где polling-запросы деградируют. Не делай DELETE огромных диапазонов одним стейтментом (он конкурирует за локи со вставками); удаляй отправленные строки маленькими батчами или партиционируй outbox по дням, чтобы очистка была metadata-only DROP PARTITION вместо построчных удалений, бьющих по индексам.
• Порядок. Один relay сохраняет порядок created_at. Как только ты масштабируешь до нескольких relay ради throughput, два воркера могут публиковать одновременно, и события приходят не по порядку. Если consumer’у нужен порядок в рамках агрегата, ключуй по aggregate id, чтобы все события одного заказа шли в одну partition и к одному воркеру.
• Конкурирующие relay. Запусти две реплики relay наивно — и обе сделают SELECT тех же неотправленных строк и опубликуют их дважды. Фикс — SELECT ... FOR UPDATE SKIP LOCKED (Postgres / MySQL 8.0+): каждый воркер берёт и лочит непересекающийся батч, пропуская строки, что уже держит другой воркер, поэтому реплики масштабируются, не наступая друг на друга.