Оптимизация автоматического подбора объявлений
RiseX
Платформа автоматического подбора объявлений уже несколько лет стабильно функционировала. Но по мере роста объёмов появилась закономерная проблема: часть сделок формировалась при уже недоступных реквизитах. Это приводило к тому, что:
- Средства пользователей блокировались на неактуальных операциях
- База данных наполнялась лишними транзакциями
- Общая нагрузка на систему возрастала без практической пользы
На практике это выглядело так: из каждой 1000 созданных сделок примерно 200 приходилось отменять, потому что в выбранном объявлении не оставалось доступных реквизитов, и закрепить реквизит за сделкой было невозможно. Проблема выявлялась уже после создания сделки, когда система пыталась назначить реквизит, но не находила доступных вариантов. Это создавало ненужную нагрузку на базу данных и очереди, а также ухудшало пользовательский опыт.
После переработки алгоритма система начала оценивать доступность реквизитов на этапе подбора объявления, ещё до оформления сделки. Это позволило отсекать заведомо неподходящие варианты заранее и избавило приложение от избыточной операционной нагрузки.
Цель
Нужно было разработать надёжный механизм, который:
- Исключает из подбора реквизиты с исчерпанным лимитом
- Гарантирует, что каждая создаваемая сделка может быть завершена
- Позволяет пользователю управлять приоритетом использования реквизитов
Ключевое требование — внедрение без остановки сервиса.
Что было сделано
Учет лимитов реквизитов
Каждый реквизит получил встроенную систему подсчёта:
- Количество фактических использований
- Суммарная сумма переводов
- Контроль лимитов в реальном времени
Как только лимит достигнут — реквизит автоматически исключается из списка доступных.
Подбор нового реквизита
После исключения исчерпанного реквизита система действует по одной из двух стратегий:
- Случайный выбор — из доступных вариантов
- По приоритету пользователя — если приоритет задан в личном кабинете
Это позволяет гибко настраивать поведение в зависимости от бизнес-потребностей.
Обновление лимитов через события
Механизм реализован на событиях:
- Сделка завершена — статистика реквизита обновляется
- Сделка отменена — данные не меняются
Подход избавляет от необходимости выполнять тяжёлые проверки в фоновом режиме и делает систему более масштабируемой.
Фильтрация на раннем этапе
Сделки с реквизитами, не проходящими по лимитам, отсекаются ещё до оформления. Это избавляет платформу от создания нерелевантных операций и снижает нагрузку на БД.
Результаты
- Система перестала создавать "пустые" сделки
- Уменьшилось количество лишних операций и обращений к БД
- Ускорилось оформление сделок
- Повысилась стабильность и предсказуемость
- Пользователи получили прозрачный контроль над порядком использования реквизитов
Технологический стек
- Laravel — основной фреймворк, событийная архитектура, очереди
- Redis — кэширование лимитов реквизитов, хранение счётчиков, очередь задач (Redis driver)
- Laravel Queue — асинхронная обработка статистики и обновлений
- MySQL — основное хранилище данных и пользовательских приоритетов
Почему это важно
Подобные задачи не решаются готовыми решениями. Здесь важно понимание бизнес-логики, устойчивость архитектурных решений и точность при работе с транзакциями.
Мы понимаем, как устроены финансовые процессы внутри сложных систем, и умеем не просто "написать код", а встроиться в критическую точку и сделать её надёжной и масштабируемой.