Помогаем сети ресторанов разобрать монолит и унифицировать стек

ROSTIC'S — крупнейшая российская сеть ресторанов в сегменте быстрого обслуживания, насчитывающая более 1300 заведений. В 2020-м команда Evrone участвовала в разработке CRM-системы на Ruby для управления собственными точками и поддержки франчайзи.

Сегодня компания продолжает развитие и её цифровые сервисы выдерживают высокую нагрузку и подключение новых ресторанов. Существующая CRM справлялась с задачами, но стала слишком громоздкой для реализации новых функций. Например, из-за роста количества заказов поиск по миллионам записей в PostgreSQL мог занимать до 30 секунд, что критично для операционной работы и поддержки.

Мы усилили команду ROSTIC'S техническими специалистами и участвовали в решении вопросов производительности и хранения персональных данных, в разделении Ruby-монолита на микросервисы и их переводе сначала на Go, а потом на .NET. Наша работа позволила команде клиента сохранить стабильность сервиса в условиях нагрузок, а также обеспечила надежный фундамент для развития.

Проблема — «узкие места» монолита и вызовы масштабирования

CRM, созданная при поддержке команды Evrone служила «мастер-системой» для всех справочников данных — от меню до параметров ресторанов — а также помогала управлять первой и второй линиями поддержки и работать с заказами, клиентами и маркетинговыми возможностями. Однако архитектура, которая была оптимальной на старте, со временем столкнулась с двумя критическими барьерами и поэтому потребовала изменений.

Кризис базы данных и терабайты JSONB

С ростом сети до 1300+ ресторанов и быстрым развитием доставки нагрузка на PostgreSQL достигла пика. Один заказ за свою «жизнь» может получить до 40 разных статусов: изменение состояния, назначение доставщика, формирование чека, возврат и так далее. Постоянная перезапись таких тяжелых объектов в БД создавала большую нагрузку и приводила к проблемам:

• Медленный поиск: сложная фильтрация по заказам могла занимать до 30 секунд или падала по таймауту, потому что база не справлялась с индексацией постоянно меняющихся огромных объектов. Служба поддержки не могла быстро отвечать клиентам, а менеджмент ресторанов не мог собрать аналитику.
• Даунтаймы: очистка терабайтов данных в БД (autovacuum) могла заблокировать запись новых заказов на несколько часов, а это недопустимо для системы, работающей в режиме 24/7.

Архитектурная связанность и ограничения Ruby

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

Также высокая нагрузка на один из компонентов системы, например, обработку заказов, замедляла работу всей системы. Это одно из ограничений Ruby — он отлично подходит для автоматизации бизнес-процессов, но начинает потреблять много ресурсов при сильном росте нагрузки.

Решение — подключаемся к команде ROSTIC'S и декомпозируем монолит

Масштабирование началось не только с выделения микросервисов из монолита, но и с запуска нескольких дополнительных сервисов, чтобы система работала быстрее, стабильнее и предсказуемее.

Ускорение поиска в 100 раз

Поиск заказов требовал переработки из-за задержек и постоянно растущей нагрузки. Для решения этой проблемы требовалась новая архитектура хранения данных и специализированные инструменты для работы с big data.

Сначала поиск перенесли из PostgreSQL в Elasticsearch, а потом сделали индексы понедельными, чтобы данные не накапливались в одном файле. Это упростило переиндексацию и сократило время отклика системы с 30 секунд до стабильных 250–300 мс. Теперь сложная фильтрация по более чем 20 параметрам занимает меньше времени и позволяет сотрудникам поддержки быстрее реагировать, а менеджерам — собирать нужную аналитику.

Оптимизация хранения и борьба с autovacuum

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

Теперь удаление устаревших данных происходит незаметно для системы, не вызывая блокировок записи новых транзакций и обеспечивая работоспособность CRM в режиме 24/7.

Внедрение Temporal для эффективной логистики

Процесс доставки заказа — это сложная цепочка событий, распределенная во времени. От назначения курьера до момента, когда еда доезжает до клиента сервисы должны много раз обменяться статусами, а внешние поставщики, например агрегаторы, убедиться в том, что заказ действительно выполняется. Если писать такой код как один большой процесс, он будет требовать слишком много ресурсов, а сетевой сбой просто приведет к потере данных. 

Для оптимизации этого процесса бэкенд-команда проекта внедрила библиотеку для Temporal, который позволяет описывать workflow доставки как набор этапов, каждый из которых может выполняться отдельно только в нужные моменты. Например, если сервис логистического партнера временно недоступен, система автоматически повторит нужный шаг после его включения, не теряя прогресс.

Такая структура кода также решает проблему вечно устаревающей документации: разработчикам будет проще вникнуть в контекст, а аналитикам больше не нужно просить разработчика обновить схему в Confluence — актуальная визуальная карта процесса строится прямо из работающего кода.

Внедрение SDK и «шаблона микросервиса»

По мере распила монолита и разделения команд по разным технологическим стекам (Ruby, Go и .NET) разработка превратилась в «зоопарк», где каждый новый сервис проектировался с нуля. Это приводило к тому, что инженеры тратили время на написание однотипного инфраструктурного кода (boilerplate), а отсутствие единых стандартов мониторинга мешало следить за сбоями.

Интегрируясь во внутренние инженерные команды, мы помогали спрявляться с рутинным кодом и выделять общие компоненты в отдельные библиотеки. Например, Observability SDK унифицировал логирование, сбор метрик и трассировку во всей экосистеме, а в Web SDK вынесли весь повторяющийся код для работы с веб-запросами.

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

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

Безопасная аутентификация и защита данных

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

Команде пришлось полностью пересмотреть подход к идентификации, внедрив систему на базе JWT-токенов и выделенного сервера авторизации Keycloak. Чтобы фронтенд мог эффективно взаимодействовать с новыми компонентами, добавили слой BFF (Backend for Frontend) на Node.js, который взял на себя проверку токенов и агрегацию данных.

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

Модернизация Frontend: от Ruby-шаблонов к React

Фронтенд CRM-системы сначала создавался на Vue.js, который был жестко связан с бэкендом и отрисовывался непосредственно через Ruby on Rails. Это позволило запуститься быстрее, но вся разработка велась в рамках одного репозитория, а это затрудняло масштабирование и смешивало ответственность между командами. 

Вместе с командой клиента было принято решение о переезде на новый фронтенд-стек. Сначала отделили отрисовку интерфейса от бэкенда, а затем провели масштабную миграцию с Vue.js на React и TypeScript. 

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

Обновление backend: переезд на .NET

Из-за того, что основная часть системы была реализована на Ruby, некоторые микросервисы на Go и .NET, а контекст между проектами мало пересекался, разработчики были фактически «заперты» внутри своих команд, и их невозможно было оперативно перебрасывать для решения приоритетных задач между разными частями системы.

Кажется, что следует придерживаться логики «работает — не трогай», но в масштабах сети из более чем тысячи ресторанов доступность ресурсов и скорость ротации важнее привязки к конкретному языку, поэтому команда ROSTIC'S приняла стратегическое решение о переходе на «моностек» на базе .NET и начала планомерный перенос бизнес-логики.

Сначала были переписаны ключевые сервисы клиентского опыта (аутентификация, профили), а затем началась постепенная трансформация Ruby-монолита в независимые .NET-микросервисы.

Полный вывод старых Ruby-компонентов еще не закончен и некоторые функции работают еще из старого монолита, но результаты уже заметны. Например, переход позволил упростить управление разработкой: теперь разработчик из команды «Заказов» может бесшовно подключиться к задачам «Меню», так как везде используется одинаковая архитектура и инструменты. 

Ускорение подключения партнеров

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

Решением стал универсальный «фасад» подключения доставки, который избавил от бесконечного написания однотипного кода. Теперь интеграция нового партнера строится по принципу «80/20»:

• 80% логики уже реализовано в готовом каркасе (управление жизненным циклом заказа, общие сценарии обработки и базовые интерфейсы).
• всего 20% логики нужно реализовать отдельно: специфические особенности конкретного партнера, соотнесение уникальных статусов с внутренними состояниями нашей системы, настройка методов авторизации.

Такой подход снизил затраты на разработку и ускорил Time-to-Market. Бизнес может подключать новые курьерские службы и выходить в новые регионы быстрее, используя отлаженную базу и «оборачивая» уникальные требования партнеров в универсальные абстракции.

Улучшение отдельных сервисов ROSTIC'S

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

Например, мы стали частью команды разработки сервиса умных зон доставки. Изначально проверка доступности доставки была сложным процессом, который не всегда давал мгновенный и точный результат. ROSTIC’S решили создать сервис, работающий с геопространственными данными, внедрили систему хранения и поиска вхождений в полигоны, которые описывают зоны ответственности вокруг каждого ресторана. Теперь, когда пользователь указывает свои координаты, система мгновенно проверяет их по гео-индексам и подтверждает возможность доставки 

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

Результаты: от стабилизации поиска до технологического лидерства

Специалисты команды Evrone стали частью технических командах ROSTIC’S, которые добились хороших бизнес-результатов в самых разных направлениях:

Внутренние сервисы ROSTIC'S перешли от ручного ввода данных к алгоритмическому прогнозированию на основе истории. Новая архитектура хранения ПД и система аутентификации обеспечили полное соответствие стандартам ФЗ-152 во всех цифровых каналах.

Система успешно справляется с высокой нагрузкой, обеспечивая обработку заказов с задержкой не более 3 секунд. Поиск по заказам теперь работает быстро благодаря переносу из PostgreSQL в Elasticsearch: среднее время отклика сократилось с критических 25-30 секунд до стабильных 250–300 мс. Сложный поиск также ускорился: если раньше мульти-фильтры могли привести к таймауту, то теперь даже самые тяжелые запросы за 15-месячную историю заказов укладываются в 5 секунд. 

Переход на «моностек» .NET позволил компании эффективно жонглировать ресурсами: разработчики могут бесшовно переключаться между командами («Меню», «Заказы», «Клиенты»), а онбординг новых сотрудников проходит быстрее.

Нужна помощь в обновлении продукта?

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