📲Паттерн Outbox

Каждый, кто хоть раз настраивал обмен из 1С (очереди сообщений) с внешними системами через HTTP-сервисы, сталкивался с болью: как гарантированно отправить событие...?!

Итак, сегодня речь про паттерн Outbox. Это элегантное архитектурное решение, которое устраняет одну из самых коварных проблем распределённых систем: проблему двойной записи. В мире микросервисов, где обновление БД и отправка события часто происходят в разных системах, риск потери или дублирования информации особенно высок.

Типичный сценарий в интернет-магазине: клиент оформляет заказ. Сервису заказов нужно не только сохранить этот заказ в своей БД, но и отправить событие в брокер сообщений (Kafka, RabbitMQ и т.д.). Это событие необходимо, чтобы другие сервисы (например: 1С УТ) могли отреагировать и выполнить свою работу. Но эти две операции не атомарны. Возможны сценарии: ✅заказ сохранён, но событие не ушло ✅событие ушло, а транзакция откатилась (проблема двойной записи)

Решение – Outbox: В одной транзакции сохраняем и бизнес-данные, и запись о событии в специальную таблицу. Отдельный процесс читает из неё и отправляет сообщения во внешнюю систему. Гарантия: либо всё сохранилось, либо ничего. Плюсы и минусы паттерна: ➕ атомарность, надёжность, асинхронность ➖ возможны задержки и дубликаты

Это вполне реальный и востребованный инструмент для построения отказоустойчивых и согласованных интеграций с внешним миром. Основная идея заключается в том, чтобы сделать базу данных единым источником правды для бизнес-данных и исходящих сообщений. Вместо того чтобы пытаться синхронизировать БД и брокер сообщений, сервис сохраняет всё в своей собственной БД.

Статьи на Хабре о паттерне Outbox : 🌐 От теории до продакшена 🌐 Как не растерять сообщения в микросервисной архитектуре

#Практика1С