CodeNull

В стародавние времена это действительно было проблемой.

И обычно использовался п.2, который называется EAV, и который в нормальном виде (таблица всех атрибутов, таблица всех значений, и таблица-связка товар-атрибут-значение), хотя и является истинно реляционным решением, служил причиной кровавых слез не одного поколения программистов.

Эта ситуация послужила одной из причин появления хранилищ для неструктурированных данных, таких как Монго, которые входят в очень широкую категорию NoSQL.
Но сами по себе "документо-ориентированные базы данных" в качестве основного хранилища - это ад и проклятие, хуже EAV. Если EAV делает адом только работу с атрибутами товаров, то Монга делает проклятием работу со всей БД целиком. Забудьте об этой идее.

Тем более что в последние годы появилось вполне достойное решение: во всех классических СУБД появилась поддержка JSON полей.
То есть таблица товаров будет самая обычная, в которой есть общие поля типа цены, названия и прочее. А свойства хранятся в JSON поле. Беря, таким образом, лучшее из двух миров.

На начальном этапе вы даже сможете делать поиск по атрибутам, используя нативные JSON функции. Но в дальнейшем поиск товаров, а так же фильтрацию по атрибутам на странице категории (так называемый "фасетный поиск") надо будет возложить на специальный поисковый движок (который тоже входит в широкую категорию "NoSQL", хотя ничего общего с документными БД не имеет, и БД, собственно, не является), такой как Эластик или Мантикора.

Главное при этом хранить (либо в коде, либо в таблице категорий) эталонные структуры таких json полей, которые, во-первых, использовать как справочники для заполнения товаров (тупо чтобы помнить, что частота процессора называется freq, а не frequency), и чтобы собственно делать фасетные фильтры.

Думаю, что надо ещё раз прочитать что такое ветки и коммиты в git.

Никакого отношения между ветками в git нет. Ветка это просто указатель на коммит. У каждого коммита есть родитель(-и) и всё.

Т.е. не «из ветки main создаем feature1», а «создаём новый указатель на коммит на который сейчас указывает ветка main (или чаще просто на текущий коммит) и называем его feature1». Всё. feature1 ничего не знает ни о какой ветке main, поэтому вопрос о родителе ветки бессмысленен.

Можно создать приложение common и там создавать общие модели ну и всякая разное.

Вы пытаетесь сравнить тёплое с мягким.

rest - архитектурный подход.
Axios - библиотека для отправки http запросов.
Babel - транспайлер.
Webpack - сборщик/бандлер.

Каким боком тут сервер и питон я не понял, тк всё перечисленное работает в браузере.

На будущее: Если планируете грандиозное обновление, то необходимо всегда делать бэкап. Это золотое правило любого уважающего себя разработчика. Не стоит пренебрегать бэкапом. Это может спасти ваши нервы и время.
Теперь рассмотрим ситуацию, когда восстановить из бэкапа невозможно, но есть конфигурационный файл.
Принцип такой: через интерфейс : сравнить/объединить удаляешь новое, восстанавливаешь старое. По веткам иеархии метаданных переходишь и выбираешь, что удалить, а что оставить.
Вариант, когда нету конфигурационного файла и нет бэкапа. Через отладку комментируйте строки, где появляется ошибка.
Вариант, когда есть конфиг. файл, нету бэкапа и нет возможности его использовать, либо не получается:
Отдать специалисту вопрос.
Надеюсь понятно расписал.

Смотри. Уже прошло время когда все пилили монолиты на микросервисы. Щас пошло переосмысление.
Объективно есть 2 причины пилить. Первое - организационная. Команда по какой-то причине не хочет
или не может поддерживать приложение. Или там что-то с бизнесом. Слияние. Поглощение. Передача
проекта другой команде в поддержку. Тогда берут и ставят задачу раздела отвественностей.
Конвей про это писал еще.

И второе - это баланс нагрузки и децентрализация. Про failover тут еще даже речи нет. Это
тяжелая тема и распилить монолит так чтобы его части были отказоустойчивы очень трудно. Более
того в случае синхронных взаимодействий между частями микросервисов может быть даже падение
перформанса. Да. Теоретики которые там пишут восторженные отзывы - совершенно игнорируют
накладные на RPC. И не упоминают что в монолите цена RPC была равна нулю. Иногда RPC заменяют
на MQ - но это новая архитектура и это надо полностью переделывать бизнес.

И что делать с базой данных? Это тот еще вопрос. Я почти готов спорить что вы базу пилить не будете.
И что в результате будет? Иммитация микро-сервисов? Где слабая связность?

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

Но имеет смысл сделать модуляризацию монолита. Например что там...

application
- sales
- hiring
- userprofiles

Тоже очень полезно для управления сложностью. И пускай себе будет монолит зато будет сильный
контроль за изменениями.

Тут подходит любая реляционная SQL БД потому что нет противопоказаний. Реляционку мы выбираем
уже более 30 лет как default вариант и почти не ошибаемся.

Когда задача имеет признаки ярко выраженной high-load системы - мы делаем ей частичную денормализацию
и раскладываем ее в NoSQL Key-Value решение. Но это не про улучшение а это про неизбежность. У нас нет выхода просто.
Иначе мы клиенту не сможем быстро отдать какой-то резуальтат.

Когда задача имеет ярко выраженную документную природу (нет спецификации на values) - мы берем MongoDb/CouchDb.

Когда задача хранит граф и ищет в графе и вообще требует графовых алгоритмов - то мы берем Neo4j или ей подобные.

Когда задача хранит данные измерений (телеметрия) - то предпочтительно взять InfluxDb или ей подобные. Здесь-же мы предполагаем что у нас - не будет joins а будет только измерения в диапазоне времени.

Но в данном ТЗ и на картинке обычная SQL БД (MySQL/Postgres) вполне себе нормально справляется.

Работать это будет примерно никак. Код похож на заготовку для какого-то урока по написанию апишки из джанги.