Comments 4
CDC через чтение WAL лога не позволяет обеспечить транзакционность между изменением и уведомлением об этом изменении. К примеру, мы хотим всегда быть уверены что при изменении записи в исходной базе, мы успешно отразим это в другом сервисе. И если это не получилось сделать, то нужно откатить исходное изменение. Transactional outbox в данном случае куда применимее.
Вся разница между outbox и transactional outbox заключается в том, что в первом случае изменения хранятся в wal логе, а во втором случае - в таблице.
Процессы нотификации другого сервиса в обоих случаях асинхронные - а стало быть и откатывать состояние могут одинаково.
Откатывание стейта связанных микросервисов - это же паттерн saga, но его реализуют и на обычном outbox.
Ну кроме самих изменений хочется хранить еще мета-информацию о статусе синхронизации. Скажем, в табличку я могу докинуть поле, которое отражает успешно ли сообщение отправлено брокеру или нет, время последней попытки, еще какие-то связанные метрики, и т.д. В случае с WAL-логом сложно будет обеспечить дискретность сообщений - придётся всё равно где-то state хранить.
Опять же с табличкой есть вариант делать оркестрацию на самом сервисе, а если у вас WAL вычитывает кто-то еще, то да, хореография с сагами скорее всего неизбежны.
PS: transactional outbox можно запилить не только на триггерах. Для такого паттерна мы используем возможности ORM'ки - в хуках транзакция не закрыта и можно докинуть в неё нужные SQL выражения.
мы используем возможности ORM'ки - в хуках транзакция не закрыта и можно докинуть в неё нужные SQL выражения
Круто! Видел похожий подход в статье https://debezium.io/blog/2018/09/20/materializing-aggregate-views-with-hibernate-and-debezium/
правда там ORM'кой таблички джойнили для CDC, а не transactional outbox организовывали.
Change Data Capture (CDC) в Yandex Data Transfer: гид по технологии с примерами