Создаваемое решение состоит из следующих основных частей:

Все части могут быть реализованы в микросервисной архитектуре, т.ч. каждая из них живёт в своём отдельном докер контейнере.

Требования к бекенду

Что он умеет делать

  1. Отдаёт данные на фронт. По запросу от фронта идёт в БД, выбирает необходимые данные, подгототавливает (если требуется), отдаёт в ответе на запрос.
  2. Добавление фактических данных. Принимает входящий запрос на добавление исторических данных по продажам, обрабатывает их и складывает в БД. Думаю, стоит реализовать простой и адекватный способ добавления данных, не обязательно самый оптимальный. Оптимальный будет делаться уже под требования заказчика.
  3. Запускает и управляет процессом инференса. По расписанию (раз в день) или после обновления исторических данных начинает процесс прогнозирования. Для этого идёт в БД, выбирает необходимые данные, передаёт их в ML сервис, получает прогноз и складывает его в БД.

Handlers (ручки)

get, /categories

Возвращает товарную иерархию.

{"data": [
  {"sku": "abc12",
   "group": "dfsdf",
   "category": "sdfsdf",
   "subcategory": "sdfdfs",
   "uom": 1},
  {"sku": "asdf12",
   "group": "sdfdfsdf",
   "category": "2134dfsdf",
   "subcategory": "sdfd456fs",
   "uom": 1},
 ...
]}

get, /sales

Возвращает временной ряд с информацией о количестве проданных товаров. Обязательные входные параметры запроса: id товара, id ТЦ.

{"data": [
  {"store": "store1",
   "sku": "sku1",
   "fact": [
     {"date": "2023-01-15",
      "sales_type": 0,
      "sales_units": 5,
      "sales_units_promo": 4, 
      "sales_rub": 6.7,
      "sales_run_promo": 8.9},
     {"date": "2023-01-16",
      "sales_type": 0,
      "sales_units": 2,
      "sales_units_promo": 6, 
      "sales_rub": 9.6,
      "sales_run_promo": 3.4},
     ...
    ]     
 },
  ...  
 ]
}

get, /shops