Есть вопрос с гениям архитектурных строений. Есть некоторое количество одоо

инстансов, которые обмениваются данными с главным одоо инстансом, а также есть мобильное приложение, которое обменивается данными также с главным инстансом. В мобильном приложении необходимо получать real-time данные со всех одоо инстансов, как лучше реализовать данную архитектуру? (Любые предложения и подсказки приветствуются)

Для примера: у десяти инстансов есть продукт, они обновляют его количество, данные о нем, а данный продукт продается в мобильном приложении, отображая, где и сколько продукта есть в наличии.

если есть "главный" оду, с которым обмениваются все остальные оду, значит данные для мобильного приложения нужно тянуть из него. Если тянуть данные из всех(каждой) оду в приложение, то будет хаос. Конечно при модификации данных в дочерней оду, данные попадут в "главную" оду с некоторой задержкой. Плюс время на передачу из главной - в приложение. И получается - не очень то "риалтайм". Поэтому нужно уменьшить время передачи в чентральную оду. Для это нужно чтобы способ передачи данных был НЕ ПО КРОНУ!!!! НЕ ПО КРОНУ! А по событию изменения данных. И данные передавать нужно через прямое подключение оду-оду по http. В таком случае передача одного объекта(читай небольшого массива данных) - не должна занимать слишком много времени. До 3-х секунд! Ну и конечно же - не гонять по этой интеграции бинарные данные типа картинки товаров, а использовать CDN и гонять урлы на файлы. Файлы шарить между разными инстансами. А приложение, ябы вообще сделал, чтобы брало данные из "главной" оду - онлайн. Т.е. чтобы приложение не хранило бы данные в "своей" базе данных, а брало бы данные онлайн из "главной" оду по json-rpc.

иметь в главном оду консьюмер который обновляет остатки по дочерним инстансам и ему отправлять сообщения на события с дочерних? или реалтайм запрос async/await распараллеленый на дочерние? @DontWantWakeUp а чем обусловлена такая архитектура - основной инстанс и дочерние? почему не все в одном (на разных складах напр) - нагрузкой или еще чем-то?

Немного ошибся при описании проблемы Главная оду используется только как для подписочной системы дочерних, там просто crm, инвойсы и тому подобное, нет ни складов, ни продуктов. Каждый инстанс это отдельная ерп система для каждого заказчика, в которой он уже ведет свой учет продуктов и их актуальность. А мобильное приложение используется как точка доступа для поиска нужного продукта как можно ближе к конечному потребителю(аптеки и мед препараты). То есть мы получаем главная система-наша оду, десятки одоо инстансов наших заказчиков, которые продают свои мед товары и мобильное приложение, которое они используют для продажи

Вы говорите "в главной оду нет продуктов", но "есть инвойсы". Это как? А что написано в инвойсах? Продукт под названием "Продукт"? Вы говорите, что цель: > мобильное приложение используется как точка доступа для поиска нужного продукта Значит инфо по каждому продукту - нужно иметь. Остатки по каждому продукту - тоже. Список складов и их адреса - тоже. Возможно - для консолидации этих данных и реализации функции поиска "нужного продукта как можно ближе к конечному потребителю" Вам стоит поднять еще одну оду, в которую будут литься все эти данные. И ее интегрировать с приложением. Т.е. все эти данные НЕ заливать в базу приложения, а сделать как сервис "Приложение спрашивает у этого сервиса:" нужны продукты 1, 2 и 3 клиент находится по адресу Х найди ближайшие точки, в которых есть эти продукты. и сервисная оду, отвечает уже готовым ответом Приложению. Ну а как данные попадают в базу этой оду - я описал выше: передаются по событиям, онлайн.

А не будет ли тогда проблем с согласованностью данных и овербольшой нагрузки на одну одоо? Ей придется общаться как между Odoo инстансами, так и мобильным приложением

дык - воркеров-то не один. Можно вообще для этой цели купить железяку с многоядерным сердцем и на каждое ядро повесить по воркеру. оптоволокно несколько сетевух ... олдскул рулит)

Миллион раз писал не стоит крутить маркетплейс на Odoo ! Как уже писали выше без шини не обойтись. У нас были похожие задачи. Zato + Kafka + кролик + Редис + свои балансировки в одушках ... Есть пару идей как но чистой Odoo такое собирать .