Надеюсь никто не воспользуется вашим советом.

Ну вроде тренд ушел на хранение в постгрес жсон полях) раньше еав был популярным

Так поиск тут тоже не спасет.
Поиск по большому количеству малоселективных полей всюду фигово работает, даже в ES.
Если реально тяжелая проблема - то нужно делать свой велосипед.

В Яндекс.Маркете, кажется, когда-то была своя база на каждую категорию с индексами. Впрочем, тоже работало не очень.

Как сделано у нас: есть общая реляционная бд где лежат данные о продуктах, и есть солр. Каждые N минут пробегает SQL запрос, который находит недавно обновленные продукты (по разным параметрам; от простого времени обновления до связей со стоками, ценами, каталогами, и тд и тп), и обновляет их в солре.
Но недавно мы заметили что это решение начало тормозить (слишком много факторов на которые смотрит SQL запрос, из-за этого он стал монструозным), и переписали на новое решение. Теперь у нас у моделек продуктов и связанных моделек (те же стоки, прайсы, и тп) есть after save listeners, которые при обновлении данных записывают id продукта в специальную таблицу. А потом раз в N минут все продукты из этой таблицы обновляются в солре

Ps модели - это маппинг орм на бд, энтити (у нас спринг)

А какой объем данных? :)

Обьём данных "проект начинаем через месяц, формируем стэк и команду" :)
Планируется проект пока на город с амбициями на куда угодно, факторов против не видим.

Пока у нас есть месяц на попробовать какие-то решения, подогнать поиск и архитектуру, концепты погонять, оценить объёмы работ, распланировать проект и задачи, продумать что-то перед написанием собственно основного кода уже за полные деньги в режиме "херачим до дедлайна".

То есть, как я понимаю, из-за объёма данных и роста количества поисковых критериев, вы сделали отложенное обновление данных?
Интересное решение, однако. Галочку надо поставить :)

А почему центр нотификаций в базе, а не в сервисе, который ее изменяет?

А вам точно нужно хранить описания товаров в PG? А не в том же SOLR/ES?
Ну и сколько товаров планируется? 10K? 100K? 10mln?
Просто может проще загрузить их все в память и там искать?
Если 100K, то может быть быстрее просто перебирать список, даже без индексов )
И, да, вам еще будет нужен фасетинг, раньше он был только в SOLR, сейчас не знаю. Ну или руками делать...

Насчёт планируется попрошу посмотреть выше. Я не могу говорить за то, взлетит проект или нет у заказчика. Решение делается среднее, не тяп-ляп, но и не оверинженеринг. Первый раз в команде делаем проект в поле e-commerce, поэтому только изучаем практики, и не хочется сразу вляпаться в wordpress с десятком плагинов и потом это расхлёбывать. Примерно такая точка зрения у команды. Ищем нормальные инструменты и подходы. Не худшие (чтобы не учиться плохому), и не лучшие (квалификации не хватит).

Solr/ES разве обеспечивают персистентность данных? Казалось, in-memory-хранилище и надёжность это вещи протовоположные.

faceting есть в MeiliSearch, но этот движок ну очень уж простым выглядит. Хоть и обещает многое. В других не смотрел осознанно этот параметр.

Ну, НФТ все равно надо с заказчика собрать. "Один город" - ничего не говорит о количестве товарных позиций, это могут быть и яхты (20 штук) и аптека (десятки тысяч товаров) и автозапчасти (там вообще другие проблемы).
Ну и нагрузка тоже важна. Одно дело 1 поиск в секунду, другое дело 100.

SOLR/ES конечно про персистанс. Там нет транзакций, но вообще все хранится достаточно надежно, это не in-memory хранилища.

Можно вообще EventSourcing прикрутить для хранилища и раскидывания по поисковым узлам, но все советы без понимания НФТ - бесполезны.

На уровне региона - десятки тысяч заявок, думаю, будет. Простои уровня "твой товар не отображается N секунд до обновления индекса", думаем, позволительны.

Хм. Может и правда попробовать просто мейнстримный ES.

А что подскажете насчёт архитектуры и хранения в таблицах БД? Каким образом эти категории и фильтры принято хранить в нормальных системах?

Это огромный монолит, наверное поэтому

Заявки на покупки - это как раз лучше в PG
А вот список товарных позиций с описанием - можно и в SOLR.
Или в PG и зачитывать в память при старте сервиса (и это будет самым эффективным скорее всего)

Karl Wiegers, кстати, хорошо описывает работу с требованиями в условиях итеративной/инкрементальной/Agile разработки. А еще лучше это описывает Dean Leffingwell.

Если вы не прототипируете UX/UI, то, с высокой долей вероятности, после появления первой версии продукта, у вас возникнет желание пересмотреть требования по мере роста полноты информированности. Именно поэтому уже несколько человек посоветовали вам не писать все требования заблаговременно. Вообще, выбор SDLC-модели - это достаточно обширная и непростая тема.

Коллеги, добрый вечер! Посоветуйте, пожалуйста, что почитать по поводу job/task queue. Возник специфический юзкейс динамического пайплайна, который в архитектуру kubeflow/airflow не вписывается никак (пока). А если заодно подскажете, что там есть в плане очередей для этого в Azure, будет просто прекрасно. Заранее спасибо :-)