Настроили сервис подбора объявлений – сэкономили 72% времени на изменения
Finex
Коротко, что получилось
После подключения инструментов профилирования (Laravel Debugbar, SQL-логирование) было зафиксировано 16 685 запросов при загрузке одной страницы. Основные причины:
- Было – 4,5 часа на внесение любого нового правила
- Стало – 15 минут — без правок кода
- Результат – +18 % успешных сделок и -40 % обращений в поддержку
- Технология – вместо «спагетти-кода» — цепочка независимых шагов (пайплайн)
Три года платформа росла вместе с бизнесом — покупатели находили нужные объявления буквально в пару кликов. Но чем больше требований появлялось, тем дольше мы «ковырялись» в коде. Каждое новое условие тянуло за собой десятки правок и недельное тестирование.
Мы решили убрать это «узкое горло» раз и навсегда. Цель была проста и амбициозна – сделать систему настолько гибкой, чтобы любой новый фильтр или правило включался за минуты — без участия разработчиков и задержек для бизнеса.
Описание системы
До – одна громоздкая программа, где любое новое правило «тянуло ниточку» правок по всему коду.
После – цепочка независимых шагов — как конвейер, где каждый блок отвечает только за свою операцию.
- Фильтр по доступности отметает объявления, где нет товара на складе. Сервис не показывает пустые объявления – улучшается пользовательский опыт.
- Проверка цен – сравниваем со средней рыночной. Убираем завышеные лоты, чтобы росла конверсия в покупку.
Принципы, на которых держится новая архитектура
- Конвейер (Pipeline). Процесс из «кубиков»-пайпов, которые идут строго друг за другом. Логику можно переставлять местами, включать/выключать без перекомпиляции.
- SRP — одна задача = один пайп. Если нужен новый фильтр по бренду — создаём отдельный модуль, а не лезем в старый код.
- DIP — независимость от «начинки». Пайпы общаются через общие интерфейсы; меняем реализацию — остальные и не замечают.
- OCP — «закрыт» для правок, «открыт» для расширений. Добавляем функциональность через новые модули, а не редактируем старые.
- Factory Method. Система сама «собирает» нужный набор пайпов по настройке из БД: маркетинг вносит новый критерий → платформа подхватывает его на лету.
Теперь бизнес-команда меняет правила подбора через административный интерфейс, а не через Jira-таски на разработчиков. Изменения попадают в продакшен за минуты и сразу отражаются в статистике продаж.
Проблема: Ограниченная гибкость и сложность обновлений
Бизнес-команда постоянно добавляла фильтры и коэффициенты, а старый механизм не поспевал:
- одно новое условие → десятки изменений в коде;
- релизы откладывались, тесты затягивались, клиенты жаловались.
Нам нужно былосоздать структуру, которая позволит внедрять новые правила фильтрации без затрагивания существующего кода.
Решение
Гибкий конвейер (pipeline)
Цепочка независимых фильтров. Включаем/выключаем любой шаг за 1 клик, без релиза.
Управление правилами из базы данных
Менеджер меняет JSON-профиль без разработчика. Новое правило активируется за минуты.
Модульное тестирование
Каждый пайп покрыт тестами. Сервис работает стабильно даже при частых изменениях.
Кеширование частых запросов
Уменьшило нагрузку на базу данных и ускорило процесс подбора объявлений.
Результаты
- Гибкость и скорость адаптации — новые бизнес-правила внедряются моментально, без необходимости вносить изменения в код.
- Конверсия «просмотр → сделка» — более точный подбор объявлений привёл к увеличению количества успешных сделок.
- Снижение нагрузки на поддержку — теперь понятно, почему объявление не прошло фильтрацию, что уменьшило количество обращений.
- Рост скорости работы — кеширование и оптимизация структуры кода ускорили процесс подбора.
- Прозрачность и контроль — теперь можно легко отследить, какой пайп отсёк объявление, что упростило анализ и отладку.
Что это дало бизнесу
Что дальше?
Мы превратили подбор объявлений в конструктор, который подстраивается под рынок за считанные минуты. Следующий шаг — встроить A/B-движок прямо в пайплайн, чтобы бизнес мог тестировать новые правила «на лету» и мгновенно видеть, какие реально увеличивают доход.