Решение задачи с собеседования — проектируем динамическую фильтрацию

В прошлом посте описана задача, которую мы предлагали на собеседовании для разработчиков. Сама задача взята из практики, то есть это прямо то, чем в будущем предстояло заниматься собеседуемому, разве что с упрощением предметной области. Задача была такая: спроектировать фильтрацию результатов поиска товаров с учётом ограничений.

В задачах на проектирование чего-либо интервьюера интересует не столько сам ответ, сколько ход ваших мыслей. Вы можете не дойти до правильного ответа, или дойти с подсказкой. Рассмотрим потенциальные решения задачи и покритикуем их:
💡 Давайте присылать все данные на фронт и фильтровать там.
🚫 1кк записей передавать нецелесообразно. Более того, даже хранить фильтры на фронте не выйдет, так как они динамические и определяются конкретной выборкой. В любом случае, фильтровать должен бекенд.

💡В postgres можно спроектировать схему для хранения фильтров в связке со списком товаров, к которым эти фильтры можно применять.
🚫 Здесь не стали приводить конкретики, но отметим, что при таком подходе будут проблемы с динамическим обновлением счетчиков. А ещё такое решение несёт сложную ментальную нагрузку на разработчика.

💡Сведём задачу фильтрации к фасетному поиску. Для этого каждую единицу товара мы характеризуем набором конкретных признаков.
✅ В базе данных нам нужно завести отдельную колонку, где для каждого товара явно хранить набор его признаков и их значений. Для агрегации, подсчета количества и быстрого поиска по выбранным фильтрам можно использовать мощный механизм полнотекстового поиска.

Пример реализации такого решения с использованием полнотекстового поиска в postgres приведен в статье Faceted search using PostgreSQL full text search.

В DevFM пишу о полезном для разработчика.