Dual Write Problem

Dual Write Problem (проблема двойной записи) возникает, когда две или больше операций должны быть согласованными, но выполняются в разных системах или базах данных.

Типичный пример — запись данных в базу и публикация события в event broker.

Что произойдёт, если приложение упадёт после сохранения данных, но до отправки события?

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

Есть два стандартных решения.

1. Использование Change Data Capture (CDC)

После записи данных в базу механизмы CDC отслеживают изменения.
Инструмент или сервис CDC затем читает эти изменения и публикует их как события в event broker.

Преимущества:
• Нет ответственности на уровне приложения: приложению не нужно публиковать события — это делает CDC-инструмент
• Надёжность: CDC тесно связан с базой данных, поэтому все зафиксированные транзакции в итоге будут обработаны и опубликованы.

Компромисс: Настройка и поддержка CDC-инструментов добавляет операционной сложности.

2. Паттерн Outbox

Паттерн Outbox сохраняет события в специальную таблицу outbox в той же транзакции, в которой изменяются данные.

Затем отдельный асинхронный процесс читает записи из этой таблицы и публикует события в event broker.

Преимущества:
• Атомарность: изменение данных и запись события происходят в одной транзакции — либо оба фиксируются, либо оба откатываются.
• Eventual Consistency (конечная согласованность): события всё равно будут опубликованы, даже если первая попытка не удалась.

Компромисс:
Появляется дополнительная "обвязка":
* таблица outbox
* процесс, который читает её и публикует события.

Важно помнить
Без распределённых транзакций мы можем строить только системы с конечной согласованностью (eventual consistency).

#pattern #eventual_consistency #cdc

На связи с вами @itarchitecture