Содержание
- Проблема: почему монолит начал тормозить развитие
- База данных под давлением: миллионы заказов и терабайты данных
- Ограничения архитектуры и сложности масштабирования
- Как команда начала поэтапную декомпозицию системы
- Ускорение поиска почти в 100 раз
- Оптимизация хранения данных и борьба с блокировками
- Новая логика логистики с Temporal
- Единые стандарты разработки и шаблоны сервисов
- Безопасная авторизация и защита данных
- Эволюция фронтенда: переход к React
- Обновление серверной части и курс на .NET
- Быстрое подключение новых партнёров
- Развитие дополнительных сервисов
- Итоги трансформации
Проблема: почему монолит начал тормозить развитие
ROSTIC'S входит в число крупнейших сетей быстрого обслуживания в России. Более 1300 ресторанов, постоянный поток заказов, развитие доставки и подключение новых партнёров создавали серьёзную нагрузку на цифровую инфраструктуру.
Ранее команда разработала CRM-систему, которая объединила множество процессов:
- ✅ управление ресторанами;
- ✅ поддержку франчайзи;
- ✅ обработку заказов;
- ✅ маркетинговые активности;
- ✅ работу служб поддержки.
На старте такое решение отлично справлялось со своими задачами. Однако рост бизнеса постепенно выявил ограничения архитектуры.
База данных под давлением: миллионы заказов и терабайты данных
Каждый заказ проходил длинный жизненный цикл.
Система фиксировала:
- создание заказа;
- оплату;
- приготовление;
- назначение курьера;
- доставку;
- возвраты;
- изменения статусов.
Один заказ мог менять своё состояние десятки раз.
В результате PostgreSQL сталкивался с огромным количеством обновлений и хранения больших JSONB-структур.
Появились заметные проблемы:
🔴 поиск некоторых заказов занимал до 30 секунд;
🔴 сложные фильтры приводили к таймаутам;
🔴 аналитические отчёты строились слишком долго;
🔴 поддержка клиентов теряла время на ожидание ответа системы.
Ограничения архитектуры и сложности масштабирования
Монолит постепенно стал точкой концентрации рисков.
Несколько команд работали внутри одного большого приложения.
Каждая новая функция влияла на соседние компоненты.
Каждое обновление требовало дополнительной координации.
Кроме того, высокая нагрузка на отдельные части системы могла отражаться на всей платформе.
Для бизнеса это означало снижение гибкости.
Для разработчиков это означало рост сложности сопровождения.
Как команда начала поэтапную декомпозицию системы
Переход к масштабируемой архитектуре не ограничился выделением микросервисов.
Инженеры начали постепенно менять фундаментальные механизмы работы платформы.
В проекте принимали участие внутренние команды компании, а также специалисты Evrone, которые подключались к отдельным техническим задачам и помогали решать инфраструктурные вопросы.
Главная цель была простой:
- 🎯 сохранить стабильность;
- 🎯 увеличить производительность;
- 🎯 подготовить систему к дальнейшему росту.
Ускорение поиска почти в 100 раз
Поиск заказов оказался одной из самых чувствительных зон.
Поэтому команда изменила подход к хранению и поиску данных.
Основные шаги:
- Поиск перенесли из PostgreSQL в Elasticsearch.
- Индексы разделили по временным периодам.
- Процесс переиндексации стал значительно проще.
- Система получила более предсказуемую производительность.
Результат оказался впечатляющим:
- ⚡ время ответа сократилось с 25–30 секунд до 250–300 миллисекунд;
- ⚡ поддержка начала быстрее реагировать на обращения;
- ⚡ менеджеры получили оперативную аналитику.
Оптимизация хранения данных и борьба с блокировками
Ещё одной серьёзной проблемой стала работа autovacuum.
Очистка больших объёмов информации иногда вызывала длительные блокировки.
Для бизнеса такие ситуации были критичны.
Команда изменила стратегию удаления данных.
Теперь специальные процессы:
- запускаются ночью;
- удаляют записи небольшими партиями;
- не мешают рабочим операциям.
Система продолжила работать круглосуточно без заметных остановок.
Новая логика логистики с Temporal
Логистика доставки представляет собой длинную последовательность событий.
Каждый этап зависит от множества факторов:
- 📦 ресторан готовит заказ;
- 🚗 курьер принимает заявку;
- 📱 партнёрские сервисы получают статусы;
- 🏠 клиент ожидает доставку.
Для управления такими процессами был внедрён Temporal.
Новая модель позволила:
- разбить процесс на отдельные шаги;
- автоматически повторять операции после сбоев;
- сохранять состояние бизнес-процессов.
Дополнительным преимуществом стала прозрачность процессов.
Разработчики получили более понятную картину происходящего без необходимости постоянно актуализировать документацию вручную.
Единые стандарты разработки и шаблоны сервисов
После появления множества микросервисов возникла другая проблема — разнообразие подходов.
Разные команды использовали разные инструменты.
Разные сервисы создавались по разным правилам.
Чтобы избежать хаоса, инженеры начали выносить повторяющиеся решения в общие библиотеки.
Появились:
- 🔹 единые механизмы логирования;
- 🔹 централизованный мониторинг;
- 🔹 стандартизированная трассировка;
- 🔹 готовые шаблоны новых сервисов.
Теперь запуск нового компонента требует значительно меньше времени.
Безопасная авторизация и защита данных
По мере развития платформы менялись требования к безопасности.
Старая схема авторизации уже не соответствовала масштабам экосистемы.
Команда внедрила:
- JWT-токены;
- отдельный сервер авторизации;
- слой BFF для взаимодействия клиентских приложений с микросервисами.
Новая архитектура обеспечила:
- 🔐 единый вход для различных цифровых каналов;
- 🔐 более высокий уровень защиты данных;
- 🔐 готовность к дальнейшему масштабированию.
Эволюция фронтенда: переход к React
Изначально интерфейсы были тесно связаны с серверной частью.
Со временем это начало ограничивать скорость развития продукта.
Поэтому команда выполнила несколько важных шагов:
- Выделила самостоятельный цикл поставки интерфейсов.
- Внедрила архитектуру с BFF.
Интерфейсы стали работать быстрее, а разработка получила большую независимость.
Обновление серверной части и курс на .NET
Исторически система использовала сразу несколько технологий.
Такой подход создавал сложности при распределении ресурсов между командами.
Поэтому компания начала движение к единому стеку на базе .NET.
Сначала были перенесены сервисы клиентского взаимодействия.
Затем стартовала поэтапная трансформация остальных компонентов.
Основные преимущества подхода:
- ✅ упрощение онбординга;
- ✅ повышение взаимозаменяемости команд;
- ✅ снижение затрат на поддержку.
Быстрое подключение новых партнёров
Развитие доставки потребовало постоянной интеграции новых логистических сервисов.
Раньше каждая интеграция создавалась практически с нуля.
Позже появился универсальный фасад подключения.
Теперь:
- около 80% логики уже готово;
- разработчикам остаётся реализовать только специфические особенности партнёра.
Такой подход заметно ускорил запуск новых интеграций.
Развитие дополнительных сервисов
Трансформация коснулась не только CRM.
Отдельные команды модернизировали и другие важные направления.
Например:
- 📍 сервисы геозон доставки получили эффективную работу с пространственными данными;
- 📈 инструменты планирования начали использовать алгоритмы прогнозирования;
- 📅 системы стали учитывать сезонность, акции и праздничные периоды.
Каждый подобный сервис повышал эффективность бизнеса на своём уровне.
Итоги трансформации
За несколько лет цифровая экосистема компании прошла серьёзный путь обновления.
Основные результаты:
✔ поиск заказов ускорился почти в 100 раз;
✔ система стабильно работает под высокой нагрузкой;
✔ микросервисная архитектура упростила развитие платформы;
✔ процессы авторизации стали безопаснее;
✔ команды получили единые стандарты разработки;
✔ новые интеграции запускаются значительно быстрее.
История ROSTIC'S показывает, что даже успешная система требует постоянной эволюции. Технологический рост бизнеса неизбежно приводит к новым вызовам, а своевременное обновление архитектуры помогает не только сохранить стабильность, но и создать основу для дальнейшего развития.