Comments 6
Похоже вы создали себе проблему а потом пытаетесь ее с помощью костылей решить.
Если вы используете Kafka для синхронизации баз данных, то вам придётся отключать foreign key поскольку вы не можете гарантировать очередность поступления информации в распределенной среде.
Если у вас Kafka используется в качестве брокера сообщений, то вам надо создавать посылать полные сообщения - как нам Rest завещал ( т.. сообщение должно содержать полную информацию о продукте и категориях, а не его фрагменты.)
Ну или наконец использовать то что вы назвали inbox. Только. Дня в том, что в этом случае вы можете гарантировать очередность доставки сообщений, т.е. сообщение о создании категорий будет доставлено перед сообщением о создании продукта который эти категории использует.
Хотя и здесь возможна проблема - пока ваше сообщение о создании продукта дошло, другой клиент может послать сообщение об удалении вашей категории.
Кстати, ни один из рассмотренных вами подходов не защищает от такой ситуации.
Продукты и категории вполне могут создаваться в разных сервисах. Кто их будет объединять в одно сообщение? К тому же не каждая система-источник будет согласна поддерживать в одном сообщении два агрегата и отправлять сообщения на все продукты категории 1, если у этой категории поменялся какой-то незначительный атрибут.
По поводу удаления это стандартный кейс - его надо решать при любых интеграциях вполне стандартными обработчиками, в зависимости от бизнес-потребности. Нужно каскадное удаление - удаляем, не нужно - не удаляем.
DLQ предназначен только для ошибочных сообщений, которые никак не могут быть обработаны бизнес процессом (a-la байты перепутались и сообщение не парсится) и их нужно отложить, чтобы они не стопорили обработку остальных. Завязываться на dlq и прокачивать через него поток неконсистентных сообщений - ошибка. Inbox\outbox хороши, но медленные. Как и рабочий вариант с загрузкой в предварительные структуры без FK. Посмотрите на вариант решения достижения консистентности перед складыванием в БД спомощью kafka streams. Сложнее, но вариант быстрый, масштабируемый и надежный.
Спасибо за статью, сложная тема
Синхронизация асинхронности: Dead Letter и Inbox для обработки зависимых сообщений