🧩⚡ Как декомпозиция монолита помогла подготовить экосистему ROSTIC’S к дальнейшему росту

Как команда ROSTIC'S преодолевала ограничения монолитной архитектуры и готовила платформу к масштабированию.

Содержание

1. Когда успешная архитектура начинает мешать развитию
2. Рост нагрузки и первые тревожные сигналы
3. Почему монолит перестал справляться
4. Новая стратегия развития платформы
5. Elasticsearch вместо тяжёлых SQL-запросов
6. Борьба с блокировками и оптимизация хранения
7. Temporal как инструмент управления бизнес-процессами
8. Унификация разработки через SDK
9. Новая модель безопасности
10. Независимый фронтенд и слой BFF
11. Переход к единому технологическому стеку
12. Масштабирование интеграций
13. Дополнительные сервисы и развитие экосистемы
14. Ключевые результаты проекта

Когда успешная архитектура начинает мешать развитию

Любая цифровая платформа проходит несколько этапов развития.

Сначала архитектура помогает быстро запускать новые функции.

Позже та же архитектура начинает ограничивать скорость изменений.

Именно с такой ситуацией столкнулась команда ROSTIC'S.

CRM-система долгое время оставалась центральным элементом внутренней экосистемы компании. Платформа обеспечивала работу ресторанов, поддержку франчайзинговой сети, обработку заказов, управление клиентскими данными и множество внутренних процессов.

Однако рост бизнеса постепенно изменил требования к системе.

Количество ресторанов превысило 1300 объектов.

Объёмы доставки выросли кратно.

Количество интеграций продолжало увеличиваться.

Вместе с ростом бизнеса начали появляться технологические ограничения.

Рост нагрузки и первые тревожные сигналы

Наиболее заметные проблемы проявились в базе данных.

Каждый заказ генерировал большое количество изменений состояния.

Система фиксировала:

• создание заказа;
• оплату;
• сборку;
• передачу курьеру;
• завершение доставки;
• возвраты;
• корректировки статусов.

За жизненный цикл один заказ мог изменяться несколько десятков раз.

Такой объём операций создавал серьёзную нагрузку на PostgreSQL.

Команда начала наблюдать:

• ⚠️ деградацию производительности поиска;
• ⚠️ увеличение времени выполнения запросов;
• ⚠️ рост нагрузки на индексы;
• ⚠️ проблемы с обслуживанием больших объёмов данных.

Некоторые поисковые операции начали занимать десятки секунд.

Для бизнеса подобные задержки уже становились критическими.

Почему монолит перестал справляться

Технические ограничения проявлялись не только на уровне хранения данных.

Архитектурная связанность постепенно замедляла развитие продукта.

Каждое изменение затрагивало большое количество компонентов.

Каждая новая функциональность увеличивала объём зависимостей.

Каждая команда была вынуждена учитывать контекст множества соседних модулей.

Монолит продолжал выполнять свою задачу, но стоимость изменений постоянно росла.

Дополнительной сложностью стала высокая концентрация нагрузки внутри единого приложения.

Любой перегруженный компонент потенциально влиял на стабильность всей системы.

Новая стратегия развития платформы

Команда выбрала поэтапный путь трансформации.

Полный отказ от существующей системы не рассматривался.

Приоритетом стало постепенное выделение наиболее нагруженных компонентов.

Параллельно инженеры начали внедрять новые инфраструктурные подходы.

Специалисты Evrone участвовали в отдельных направлениях модернизации и помогали внутренним командам решать задачи, связанные с производительностью, стандартизацией и развитием архитектуры.

Главная идея заключалась в том, чтобы модернизировать платформу без остановки бизнеса.

Elasticsearch вместо тяжёлых SQL-запросов

Поиск заказов стал одним из первых кандидатов на рефакторинг.

Реляционная база уже не обеспечивала необходимую скорость обработки сложных фильтров.

Для решения проблемы была внедрена отдельная поисковая подсистема на базе Elasticsearch.

Архитектура получила несколько важных изменений:

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

Полученный эффект оказался значительным.

📉 Среднее время ответа сократилось с десятков секунд до нескольких сотен миллисекунд.

📉 Сложные фильтры перестали приводить к таймаутам.

📉 Аналитические сценарии стали выполняться заметно быстрее.

Борьба с блокировками и оптимизация хранения

Следующей задачей стала работа с накопленными данными.

Большие объёмы исторической информации провоцировали длительные процессы очистки.

Автоматическое обслуживание базы иногда вызывало блокировки.

Для круглосуточной системы такие ситуации были недопустимы.

Инженеры пересмотрели процесс удаления данных.

Новая схема включала:

1. Ночные окна обслуживания.
2. Пакетное удаление данных.
3. Контролируемую нагрузку на БД.
4. Автоматизацию очистки устаревших записей.

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

Temporal как инструмент управления бизнес-процессами

Отдельного внимания заслуживает развитие логистических сценариев.

Современная доставка представляет собой распределённый бизнес-процесс с большим количеством участников.

Каждый заказ проходит через множество сервисов.

Каждый этап зависит от внешних систем.

Каждый сбой может нарушить целостность процесса.

Для управления подобными workflow команда внедрила Temporal.

Новая модель позволила:

• 🔹 сохранять состояние процессов;
• 🔹 автоматически восстанавливать выполнение после ошибок;
• 🔹 реализовывать повторные попытки без ручного вмешательства;
• 🔹 визуализировать бизнес-логику непосредственно через код.

Фактически доставка начала описываться как последовательность управляемых сценариев вместо набора разрозненных интеграций.

Унификация разработки через SDK

После появления большого количества сервисов возник риск фрагментации инженерных практик.

Каждая команда могла реализовывать инфраструктурные задачи по-своему.

Такой подход быстро приводит к росту технического долга.

Для решения проблемы были выделены общие платформенные компоненты.

В экосистеме появились:

• библиотеки логирования;
• единые механизмы трассировки;
• стандарты мониторинга;
• шаблоны сервисов;
• типовые инфраструктурные решения.

В результате инженеры начали тратить меньше времени на повторяющийся код и больше времени на бизнес-логику.

Новая модель безопасности

Рост количества сервисов потребовал пересмотра подходов к идентификации пользователей.

Сессионная модель постепенно уступила место более современной архитектуре.

Основными компонентами стали:

• 🔐 JWT;
• 🔐 централизованная авторизация;
• 🔐 выделенный сервер управления доступом;
• 🔐 слой BFF для взаимодействия клиентских приложений с микросервисами.

Новая схема позволила упростить масштабирование и повысить уровень защиты данных.

Независимый фронтенд и слой BFF

Фронтенд также прошёл серьёзную трансформацию.

Ранее интерфейсы были тесно связаны с серверной частью.

Со временем такая модель начала ограничивать скорость развития.

Команда выполнила несколько последовательных шагов:

• отделила клиентское приложение;
• внедрила независимый процесс поставки;
• перешла на React и TypeScript;
• реализовала BFF-подход.

Теперь пользовательский интерфейс работает через единую точку агрегации данных, что существенно снижает сложность клиентской части.

Переход к единому технологическому стеку

Наличие нескольких языков программирования создавало дополнительные организационные ограничения.

Инженеры становились экспертами только внутри отдельных направлений.

Ротация между командами усложнялась.

Компания приняла решение двигаться в сторону единого стека на базе .NET.

Миграция выполняется постепенно.

Сначала были перенесены наиболее важные сервисы клиентского контура.

Затем началась декомпозиция оставшихся частей монолита.

Подобный подход повысил гибкость распределения инженерных ресурсов.

Масштабирование интеграций

Рост доставки потребовал регулярного подключения новых партнёров.

Каждая интеграция имела собственные API, механизмы авторизации и модели данных.

Чтобы избежать постоянного дублирования решений, инженеры разработали универсальный интеграционный слой.

Теперь большая часть типовой логики реализуется автоматически.

Разработчикам остаётся адаптировать только особенности конкретного поставщика услуг.

Такой подход значительно сократил сроки вывода новых интеграций в эксплуатацию.

Дополнительные сервисы и развитие экосистемы

Изменения затронули и другие направления платформы.

Отдельные команды развивали:

• 📍 геосервисы доставки;
• 📊 системы прогнозирования;
• 📦 инструменты планирования;
• 📈 аналитические механизмы.

Например, сервис геозон начал использовать специализированные алгоритмы пространственного поиска, что позволило мгновенно определять возможность доставки по координатам клиента.

Ключевые результаты проекта

Трансформация платформы принесла заметные результаты сразу по нескольким направлениям.

Основные достижения:

• ✅ ускорение поиска заказов почти в 100 раз;
• ✅ повышение отказоустойчивости критически важных сервисов;
• ✅ снижение влияния фоновых операций на работу системы;
• ✅ стандартизация разработки;
• ✅ упрощение масштабирования команд;
• ✅ ускорение интеграции новых партнёров;
• ✅ повышение безопасности обработки данных.

История развития ROSTIC'S демонстрирует, что архитектурные изменения редко являются разовой задачей. Для крупных цифровых платформ модернизация становится непрерывным процессом, который помогает сохранять устойчивость бизнеса в условиях постоянного роста нагрузки и усложнения экосистемы.