Согласованность в конечном счёте как архитектурный выбор

Проблема двойной записи

Каждый раз, когда сервис должен обновить собственное состояние И уведомить остальную систему, он сталкивается с двумя независимыми I/O-операциями:

1. Запись в базу данных (источник истины сервиса)
2. Публикация в брокер сообщений (сигнал для downstream-сервисов)

Эти две записи не имеют гарантии атомарности. Возможен любой из четырёх исходов:

Третий случай (фантомное событие) особенно опасен: downstream-сервисы обрабатывают событие для заказа, которого нет в базе данных источника. В биллинге это означает списание клиента за несуществующий заказ.

Первые два случая сбоя — потерянные события и фантомные события — нельзя устранить добавлением логики ретраев. Логика ретраев, повторно публикующая после падения, исправляет «событие потеряно при падении», но вводит «событие опубликовано дважды при ретрае». Проблема двойной записи структурная, а не операционная.

Transactional Outbox

Transactional outbox решает проблему двойной записи, убирая вторую запись из пути обработки запроса сервиса. Вместо прямой публикации в Kafka сервис записывает событие в таблицу outbox в той же транзакции базы данных, что и обновление состояния. Транзакция БД является единственным источником истины.

BEGIN;
INSERT INTO orders (id, customer_id, status) VALUES ($1, $2, 'pending');
INSERT INTO outbox (id, aggregate_type, aggregate_id, event_type, payload)
  VALUES (gen_random_uuid(), 'order', $1, 'OrderPlaced', $3);
COMMIT;

Если транзакция БД коммитится, и строка заказа, и строка outbox долговечно записаны. Если она падает, ни одна не записана. Атомарность гарантирована базой данных.

Отдельный relay-процесс outbox читает незаопубликованные строки outbox и публикует их в Kafka. После успешной публикации relay помечает строки как обработанные. Relay может быть:

• На основе polling: фоновый поток или сервис, запрашивающий SELECT * FROM outbox WHERE published_at IS NULL LIMIT 100 с интервалом
• На основе CDC (change-data-capture): инструменты вроде Debezium читают WAL (write-ahead log) базы данных и стримят вставки в outbox напрямую в Kafka без polling

Идемпотентные консюмеры

At-least-once доставка — не сбой доставки, а гарантия. Каждый консюмер в событийно-ориентированной системе должен быть спроектирован для обработки одного и того же события несколько раз с получением того же результата, что и при однократной обработке.

Стандартный структурный подход: поддерживать таблицу дедупликации, записывающую обработанные ID событий. Перед обработкой события проверить, есть ли его ID уже в таблице. Если да — пропустить. Если нет — обработать и вставить.

BEGIN;
-- Проверка дубликата
SELECT 1 FROM processed_events WHERE event_id = $1;
-- Если строки нет: обработать событие и записать его
INSERT INTO processed_events (event_id, processed_at) VALUES ($1, NOW());
UPDATE inventory SET reserved = reserved + $2 WHERE product_id = $3;
COMMIT;

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

Read-your-writes при eventual consistency

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

Решения:

• Read-after-write из стороны записи: для собственных недавних записей пользователя — читать напрямую из сервиса, владеющего состоянием (модель записи), минуя асинхронную проекцию. Требует, чтобы UI знал, у какого сервиса запрашивать данные о собственных недавних данных пользователя.
• Оптимистичное обновление UI: обновить UI немедленно при отправке, до обработки события downstream. При отклонении сервером — откатить UI. Это не исправляет underlying eventual consistency, но скрывает от пользователя его задержку.
• Sticky sessions к одной реплике: для read-реплик модели записи маршрутизировать чтения пользователя после записи к той же реплике, получившей запись, пока не догонит репликация.