Outbox и inbox: effectively-once через dual-write границу

Order service записывает заказ в Postgres, потом публикует событие “order.created” в Kafka. Между коммитом и публикацией pod падает. Заказ есть в базе. Downstream сервис инвентаря никогда не увидит событие. Заказ завис.

Почему dual-write всегда ломается

Любая последовательность “записать в базу, потом опубликовать в брокер” имеет crash-окно между двумя операциями:

Обе последовательности сломаны. Не существует версии “два отдельных write”, которая атомарна.

Outbox-паттерн: используем базу как брокер

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

BEGIN;
  -- Бизнес-запись
  INSERT INTO orders (id, customer_id, total) VALUES ($1, $2, $3);

  -- Outbox-запись (та же транзакция)
  INSERT INTO outbox (id, event_type, payload, published)
  VALUES (gen_random_uuid(), 'order.created', $payload, false);
COMMIT;
-- Публикация в Kafka происходит ПОСЛЕ коммита транзакции

Отдельный outbox-relay процесс опрашивает таблицу outbox (или хвостит Write-Ahead Log через Debezium) и публикует неопубликованные строки в Kafka, помечая их published после broker ACK.

Crash-сценарии теперь безопасны:

• Crash до COMMIT → транзакция откатывается. Ни заказа, ни outbox-строки. Фантомного события нет.
• Crash после COMMIT, до публикации relay → заказ существует, outbox-строка с published=false. Relay подберёт при следующем опросе.
• Kafka недоступна → relay ретраит. Outbox накапливается. Заказ цел в БД.

Реализации relay

Poll-based relay: запрашивает WHERE published = false ORDER BY id LIMIT 1000 каждые несколько секунд. Просто, добавляет latency равную интервалу опроса (обычно 1–5 с).

Debezium (CDC relay): хвостит Postgres Write-Ahead Log через logical replication. Публикует сразу после коммита строки. Sub-second lag. Без overhead опроса. Production-стандарт для высоконагруженных сервисов.

AWS SAM вариант: DynamoDB Streams → Lambda → EventBridge — managed CDC без запуска relay процесса.

Inbox-паттерн: дедупликация на консумере

Relay доставляет at-least-once (может опубликовать дважды, если перезапустился после публикации, но до пометки строки). Консумер должен быть идемпотентным.

Inbox-паттерн: перед применением бизнес-эффекта события запиши его id в таблицу processed_events внутри той же транзакции что бизнес-запись.

BEGIN;
  -- Проверяем, не обрабатывали ли уже
  INSERT INTO processed_events (event_id) VALUES ($1)
    ON CONFLICT (event_id) DO NOTHING;

  -- Если 0 строк затронуто, событие уже обработано — пропускаем
  IF found THEN
    UPDATE inventory SET reserved = reserved - $qty WHERE sku = $sku;
  END IF;
COMMIT;

Если событие придёт второй раз, вторая попытка упрётся в UNIQUE constraint на event_id и бизнес-запись пропускается. Effectively-once поведение с точки зрения консумера.

Обслуживание inbox-таблицы: партиционируй по event_timestamp и удаляй партиции старше retention window брокера (7–14 дней). Без очистки inbox растёт бесконечно.

Dead-letter queue: обработка невосстановимых сбоев

Не каждый сбой восстановим retry. Некорректные данные, нарушение схемы, невыполнимые бизнес-инварианты — это poison messages — никакое количество retry их не починит.

После N попыток обработки (обычно 3–5) перемести сообщение в dead-letter queue (DLQ). Основной конвейер продолжает работу; люди разбирают DLQ.

Основная очередь → [N попыток retry] → DLQ → human review
                                             → ручной replay (после фикса)
                                             → формальный reject (бизнес-правило)

Production-настройки: N = 3–5 попыток, DLQ retention 7–30 дней, алерт на рост DLQ depth. Растущий DLQ — compliance-обязательство: каждая запись — это операция с потенциальными частичными эффектами.