Video is unavailable for watching
Show in Telegram
Проблема Dual Write или как не терять данные в микросервисах
Частый вопрос на собеседованиях и классическая ловушка для новичков.
Представим сервис заказов: нужно обновить статус в БД и отправить событие в брокер (Kafka/RabbitMQ). Если делать это по очереди, мы рискуем: запись в БД пройдет, а брокер упадет. Данные разошлись, система в неконсистентном состоянии. Объединить их в одну транзакцию нельзя т.к. разные системы.
Решение - паттерн Transactional Outbox:
1. В одной транзакции обновляем заказ и записываем событие в таблицу outbox в той же БД.
2. Гарантируется ACID. Либо сохранятся обе записи, либо ни одной.
3. Отдельный процесс читает таблицу outbox и перекладывает сообщения в брокер.
Плюсы:
✅ Гарантированная доставка «At-least-once».
✅ Не нужны 2PC.
✅ Сервис не зависит от доступности брокера в моменте.
Минусы:
⚠️Риск дублей: если процесс упадет после отправки, но до пометки «доставлено». Решается идемпотентным консьюмером.
Сделал анимацию, как это работает на деле. Как вам такой формат?
Частый вопрос на собеседованиях и классическая ловушка для новичков.
Представим сервис заказов: нужно обновить статус в БД и отправить событие в брокер (Kafka/RabbitMQ). Если делать это по очереди, мы рискуем: запись в БД пройдет, а брокер упадет. Данные разошлись, система в неконсистентном состоянии. Объединить их в одну транзакцию нельзя т.к. разные системы.
Решение - паттерн Transactional Outbox:
1. В одной транзакции обновляем заказ и записываем событие в таблицу outbox в той же БД.
2. Гарантируется ACID. Либо сохранятся обе записи, либо ни одной.
3. Отдельный процесс читает таблицу outbox и перекладывает сообщения в брокер.
Плюсы:
✅ Гарантированная доставка «At-least-once».
✅ Не нужны 2PC.
✅ Сервис не зависит от доступности брокера в моменте.
Минусы:
⚠️Риск дублей: если процесс упадет после отправки, но до пометки «доставлено». Решается идемпотентным консьюмером.
Сделал анимацию, как это работает на деле. Как вам такой формат?