Приветствую. Может кто подскажет )) Есть симфони-приложение, монолит, на борту мессенджер

для ивентов и асинхронных задач. Грубо говоря можно разделить на клиентскую часть (рега клиента и прием заказов) и производство+управление товарами (создание товаров, выполнения заказов менеджерами, где у заказов меняются статусы жизненного цикла, которые должны быть видны у клиента ). Задача - разделить на два отдельных приложения клиент (может быть несколько сайтов) и производство(которое принимает эти заказы). Общение с бэка на бэк.

Две основные проблемы:
1) Много общих элементов. Например список товаров, города. При этом клиенты/заказы на клиентской части свои. Есть вариант настроить реплику master slave из производства на каждого клиента отдельных таблиц (товары например). Может какие еще варианты интересные есть?
2) Обмен сообщениями о статусах заказов. Первоначально думал по api общаться, но потом подумал, почему бы не через rabbitmq. Теже ивенты ловить, как я сейчас ловлю. Но symfony messenger вроде под несколько приложений не приспособлен. Подключать еще одну либу и кидать в отдельную очередь дубликаты сообщений-ивентов? Какую либу можете посоветовать? Или все же лучше api для такого. Ведь api так или иначе все равно будет (например если клиент хочет поменять конфигурацию заказа, а он уже ушел в реальное производство - у нас выдает месседж с ошибкой).

Буду благодарен любой идее и обсуждению :)

имхо, рановато вам в распределенные системы, имхо

Есть задача, надо решать.

решать нужно не задачи, а проблемы. Зачем нужно это разделение?

Задача - несколько сайтов принимающих заказы, один сайт производства. Клиент хочет масштабировать биз в стиле франшизы ну или как то так.

что мешает с разных сайтов запросы по прежнему слать в монолит?

Разные реквизиты оплат, разные клиенты. В прицнципе возможно все накостылять в монолите, но мне кажется выйдет огромный ком IF . Так как какие то клиенты будут обычными клиентыми, какие - то посредниками и уже другой алгоритм. Хотя тут конечно еще окончательно не решено, мб и правда не стоит делить.

с распределенной системой у вас выйдет несколько комков с ифами

я согласен, что распределюха - это куча гемора :( лучше максимально попытаться остаться в монолите несмотря на усложение логики в одном месте?

надо понимать, что вы пытаетесь решить, какую проблему? не вижу проблемы в том, что у вас будут разные клиенты, со своими реквизитами и тому подобное. Разные фронты могут прокидывать в заголовках свои clientId/API Key. Это стандартный подход

Ну одна из проблем: сейчас клиент совершает заказ на себя. А цель чтобы клиент совершал заказ как бы через диллера и уже диллер делал заказ у нас. В случае с монолитом, нужно будет совершать проверки чей клиент, через кого он работает или нет, или напрямую. А так будет просто прилетать запрос на создание заказа, и нам уже не особо важно - клиент прямой, клиент диллер. Хотя конечно наверное это можнои в монолите намутить...