Высоконагруженная платформа автоматического поиска и бронирования заказов для B2B

Заказчик делает распределённую платформу для B2B-клиентов. Клиент подключает к ней свои аккаунты, создаёт задачи со своими правилами и ограничениями, и дальше платформа сама ищет подходящие предложения на loadboard-площадках, где публикуют заказы, и автоматически выполняет нужные действия, например бронирует заказ. Кроме поиска, в платформе есть аналитика и статистика по предложениям, отчёты, биллинг и управление задачами пользователей.

Главное в продукте это скорость: поиск должен быть стабильным и быстрым, с частым обновлением данных.

Бэкенд-разработчик Фортех работал на проекте с октября 2025 по январь 2026 года, три месяца. В команде заказчика были фронтенд-разработчик, три бэкенд-разработчика, DevOps-инженер, аналитик, менеджер проекта и руководитель продукта. Когда наш разработчик перешёл на другой проект, Фортех предложил заказчику замену, и на проект вышел другой разработчик нашей команды.

Задача

• разработать основной поисковый сервис под высокие нагрузки и обновление данных до 10 мс;
• сделать распределённую координацию серверов;
• собрать пайплайн автобукинга;
• сделать отчёты по истории loadboard для всех регионов;
• подключить авторизацию, платежи и подписки;
• обеспечить отказоустойчивость базы данных;
• наладить сбор статистики, метрик и логов.

Ограничения задачи

Поиск работает с частотой обновления до 10 мс, поэтому любое медленное место в запросах или инфраструктуре сразу сказывается на клиентах.

Нагрузка распределена между многими серверами. Если один из них падает, задачи должны перейти на другой без участия людей.

Решение

Поисковый сервис. Разработчик Фортех сделал основной поисковый сервис и оптимизировал запросы и инфраструктуру под обновление до 10 мс и высокие нагрузки. Скорость поиска и фильтры клиент может регулировать сам.

Координация серверов. Реализовал распределённую систему: она выделяет воркеры, балансирует нагрузку, переключает задачи при сбоях и управляет IP-адресами.

Автобукинг. Собрал полный пайплайн автоматического бронирования: от найденного предложения до выполненного действия.

База данных. Спроектировал и внедрил шардирование и репликацию MongoDB, чтобы база выдерживала больше запросов и не падала вместе с одним узлом.

Отчёты. Сделал подсистему отчётов по истории loadboard для всех регионов с агрегациями и аналитическими срезами.

Пользователи и оплата. Подключил авторизацию и аутентификацию пользователей, платежи и подписки через Stripe.

Наблюдаемость. Сделал сбор статистики по поиску, загрузке серверов и эффективности задач с визуализацией в Grafana. Настроил сбор метрик, логов и трейсов через Prometheus и Loki, по ним находил и устранял узкие места.

Тесты. Ключевые компоненты покрыты unit- и интеграционными тестами.

Платформа ищет предложения с обновлением до 10 мс и сама бронирует подходящие заказы по правилам клиента. Нагрузка распределяется между серверами, а если один из них падает, задачи переходят на другие.

База данных работает с шардированием и репликацией. У клиентов есть отчёты по истории loadboard во всех регионах, подписки и оплата через Stripe. Команда видит статистику, метрики и логи в Grafana и быстро находит узкие места.

Когда наш разработчик перешёл на другой проект, Фортех нашёл ему замену, и работа на проекте продолжилась.

Частые вопросы

Как сделать поиск с обновлением данных за миллисекунды?
Оптимизировать запросы и инфраструктуру, распределить поиск по воркерам и следить за узкими местами по метрикам. Здесь поиск работает с обновлением до 10 мс.

Как не потерять задачи, если сервер упал?
Нужна координация серверов с переключением при сбоях: задачи с упавшего сервера автоматически уходят на другие. В этом проекте её сделали вместе с балансировкой нагрузки.

Когда MongoDB нужно шардирование?
Когда одна база перестаёт справляться с нагрузкой или её отказ останавливает весь продукт. Шардирование распределяет данные по узлам, а репликация держит копии на случай сбоя.

Что будет, если разработчик Фортех уйдёт с проекта?
Мы предложим замену. Здесь так и случилось: заказчик прошёл собеседование с новым разработчиком нашей команды, и работа продолжилась.