Скорость и непрерывность продаж в SFA-системе FMCG-производителя
Через мобильное приложение торговых представителей ежедневно проходят заказы больше чем на 100 млн ₽. Ускорили синхронизацию, каталог и поиск и сделали так, чтобы заказы доходили до дистрибьютора даже при сбое связи или дата-центра.
- В 5,2 раза — в среднем быстрее синхронизация мобильного приложения
- В 10 раз — легче изображения товаров в каталогах
- 80 → 20 минут — индексация каталога товаров с промо
Клиент и исходная ситуация
Клиент — международный FMCG-производитель. GROTEM развивает его экосистему продаж: мобильное SFA-приложение торговых представителей, B2B-портал и телепродажи. Через мобильное приложение каждый рабочий день берутся заказы чуть больше чем на 100 млн ₽.
При таком обороте любой сбой — это прямые потери выручки производителя и дистрибьюторов, а медленное приложение отнимает время визита у представителя и клиента.
Что происходило до начала проекта
- В регионах с нестабильным интернетом синхронизация могла не уложиться в 15 минут и не завершиться вовсе.
- Приложение забирало каталог мелкими порциями по 300 товаров из перегруженного сервиса: запросы падали по таймауту.
- Фото товара весило около 1 МБ и загружалось заново при каждом открытии — было видно, как картинки прорисовываются.
- В пиковые моменты методы чтения данных замедлялись с миллисекунд до 20 секунд.
- При сбое связи или дата-центра заказы, собранные в полях, нельзя было передать дистрибьютору.
Каких результатов хотел достичь клиент
Сделать так, чтобы торговый представитель и клиент не ждали систему, а заказы доходили до дистрибьютора при любом сбое.
Быстрая синхронизация
Обновлять данные в приложении за минуты даже при слабом интернете.
Отзывчивые каталоги
Открывать карточки и фото товаров без задержек на портале и в приложении.
Ровная работа в пики
Не тормозить пользователей во время массовой загрузки прайсов и остатков.
Ноль потерянных заказов
Сохранить продажи при падении связи, синхронизации или дата-центра.
Что разработала команда GROTEM
GROTEM прошла всю цепочку — от мобильного клиента до базы данных — и устранила узкие места, не меняя бизнес-логику. Отдельно команда разработала аварийный сценарий для полевых продаж.
Аварийная выгрузка заказов
Если связь или основная система недоступны, представитель включает в приложении режим аварийной выгрузки:
- приложение формирует файл с собранными заказами;
- файл уходит дистрибьютору по почте или в мессенджере — в обход основной системы;
- уникальный префикс в имени файла исключает дубли, когда синхронизация восстановится.
- BCP
- Офлайн
- Защита от дублей
Стабильная синхронизация каталога
Раньше приложение запрашивало товары напрямую у сервиса каталога, который одновременно принимал интеграции цен и промо. Теперь:
- раз в 30 минут фоновая задача забирает полный каталог в собственную базу шлюза;
- товары хранятся JSON-объектами — новые поля добавляются без миграций базы;
- обновляются только изменённые товары — по ID и хешу;
- порция данных выросла с 300 до 1 000 товаров.
- Офлайн-first
- Кеширование
- Фоновые задачи
Лёгкие изображения и гибкий поиск
Картинки конвертируются в WebP и уменьшаются «на лету» при первом запросе — без переконвертации всего архива. Браузер и приложение кешируют их на год.
Поиск по каталогу перевели на Elasticsearch: он учитывает опечатки и окончания и ищет сразу по бренду, линейке, категории, упаковке, весу и названию.
- WebP
- Elasticsearch
- Кеширование
Чтение из реплики и быстрая индексация промо
Интеграции без пауз переписывают тысячи прайс-листов и остатки, и запись тормозила чтение. Решения:
- методы, помеченные в коде как только читающие, автоматически работают с репликой базы — чтение стало в 2 раза быстрее;
- индексацию 7 000 товаров перевернули: вместо перебора «товар → все акции» система один раз строит словарь «акция → товары».
- Read-реплика
- Индексация
- Кеш
Особенности проекта
Оптимизировать пришлось живую систему: в ней постоянно работают сотни пользователей и непрерывные интеграции, а остановить продажи ради доработок нельзя.
В пределе сутки простоя означают потерю всех дневных заказов — около 100 млн ₽. Поэтому целевая метрика аварийного сценария — ноль потерянных заказов.
Аварийный файл должны принять учётные системы разных дистрибьюторов. Общие формулировки требований здесь не работают — к проработке формата нужно подключать самих дистрибьюторов.
Интеграции работают круглосуточно, и в базе нет ни секунды без записи — из-за этого методы чтения вставали в очередь.
Мобильное приложение ходило за товарами в тот же сервис, который принимает прайс-листы и промо, — его кеш постоянно сбрасывался.
Пользователи не видели прогресса синхронизации и думали, что приложение зависло. Важно было показать, что процесс идёт.
Что было важно реализовать на уровне системы
Решения подбирали так, чтобы получить эффект без переписывания бизнес-логики и без переделки данных клиента.
Что получил бизнес
Синхронизация мобильного приложения стала быстрее в среднем в 5,2 раза: сеансы, которые раньше не укладывались в 15 минут, теперь могут пройти меньше чем за минуту.
в среднем быстрее синхронизация мобильного приложения
легче изображения товаров после перехода на WebP и ресайз
быстрее методы чтения данных под нагрузкой
на индексацию каталога с промо вместо 1 ч 20 мин
- Заметно пользователям — клиент подтвердил, что фото товаров в мобильном приложении больше не прорисовываются на глазах.
- Защита выручки — у полевых продаж появился сценарий на случай сбоя: заказы доходят до дистрибьютора, даже когда основная система недоступна.
Технологии проекта
Бэкенд
Каталог и поиск
Изображения
База данных
Мобильное приложение
Мониторинг
Поможем выбрать оптимальное решение для вашего бизнеса
Разберём задачу, предложим архитектуру решения и оценим сроки реализации — на первой консультации, бесплатно.
- Покажем релевантный опыт на похожих проектах
- Сформируем решение с учётом ваших задач и IT-ландшафта
- Предложим следующие шаги без обязательств