Как мы перестроили архитектуру: от монолита на Yii1 до собственной сервисной платформы

Проект Vpodarok начинался как обычный интернет-магазин подарочных сертификатов. Со временем он стал экосистемой с витринами, API, B2B-интерфейсами и сложной бизнес-логикой. Архитектура, изначально рассчитанная на один сайт, перестала справляться с ростом функционала и нагрузки. Рассказываем, как команда прошла путь от унаследованного монолита к сервисной модели — и какие технические и бизнес-решения пришлось принять.

Первые версии Vpodarok были написаны на Yii1. Это был классический интернет-магазин, в котором можно было выбрать подарочный сертификат, оформить заказ и отправить его на почту. В течение нескольких лет над кодовой базой поочерёдно работали десятки разных команд. Код усложнялся, менялся, обрастал нестыкующимися решениями и стал плохо поддерживаемым. Тем временем проект развивался: появлялись витрины под B2B-клиентов, функции для работы с юрлицами, отчётность, API, интеграции с 1С, генерация PDF, партнёрские рассылки.

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

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

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

Начали с устранения узких мест. Базу данных перенесли на отдельный сервер, предварительно замерив задержки между дата-центрами. Для защиты от спама и избыточных запросов ввели throttle-механику от Laravel и заменили Google reCaptcha на локальное решение, пригодное для российского сектора. Laravel Telescope помог отслеживать нагрузку и поведение приложения, а критические ошибки начали поступать напрямую в Telegram-канал команды.

Параллельно команда вынесла часть наиболее ресурсоёмких операций в асинхронные очереди на RabbitMQ. Например, активация сертификатов, которая раньше шла через крон, теперь обрабатывалась через воркеры supervisor в несколько потоков. Это сразу дало прирост стабильности и снизило нагрузку на монолит.

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

Важно, что сам Processing не экспонирует публичных API. Коммуникация с ним осуществляется только через специальный шлюз — Data Connector. Он взял на себя роль фасада, агрегатора устаревших API и роутера для клиентских запросов. В результате даже старые интеграции, построенные на API v1/v2, продолжили работать без сбоев, хотя фактически уже обращались к новой системе.

Жизненный цикл заказа полностью прошёл трансформацию. Клиент оформляет заказ через API v3. В зависимости от способа оплаты — либо списываются средства с баланса клиента, либо создаётся счёт в платёжном агрегаторе и обрабатывается callback. После подтверждения оплаты Processing отправляет задачу в очередь, где воркер генерирует зашифрованный PDF-сертификат и сохраняет его в приватное хранилище. Документ можно получить через ответ API, по webhook, e-mail или SMS — в зависимости от настроек. Активация и погашение сертификата также проходят через Data Connector: он проверяет статус карты и создаёт задачу на деактивацию в Processing.

Самым важным эффектом стало разделение логики и интерфейсов. Теперь витрины, админка, партнёрские решения и интернет-магазин работают независимо друг от друга. Всё, что связано с бизнес-процессами, сосредоточено внутри Processing. Он масштабируется отдельно, обновляется отдельно и не завязан на веб-фронт. Очереди, логирование и уведомления тоже стали самостоятельными сервисами. Это позволило разгрузить основное приложение и существенно снизить нагрузку на команду поддержки.

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

Как и любой переход к сервисной архитектуре, этот путь потребовал усилий. Появились дополнительные DevOps-задачи: мониторинг, контейнеризация, поддержка множества компонентов. Стало сложнее управлять SLA — теперь даже незначительный сбой в одном из десяти сервисов мог влиять на доступность всей системы. Коммуникация между сервисами требует учёта latency и отказоустойчивости. Повысились требования к внутренней экспертизе: понадобилось больше знаний по безопасности, работе с брокерами, типам БД, синхронизации данных.

Тем не менее, эти затраты оказались оправданными. По внутренним метрикам, время на поддержку унаследованного кода сократилось вдвое, а производительность выросла в разы.

Команда продолжает переход к полной сервисной модели. В ближайших планах — окончательное разделение витрин и интернет-магазина, расширение публичного API, внедрение дополнительных уровней безопасности и мониторинга. Также рассматривается возможность использовать Processing как коробочное решение — с интерфейсом, SLA и автономным развёртыванием для корпоративных клиентов.

Переход от монолита к сервисной архитектуре в Vpodarok стал не стихийной перепиской, а планомерной эволюцией, продиктованной требованиями бизнеса. Архитектура изменилась, потому что продукт вышел за рамки одной витрины и стал платформой. Теперь система готова к росту, масштабированию и внедрению новых решений без страха «сломать всё». И хотя путь занял не один год, он стал основой для устойчивого развития продукта в долгую. Желаем всем удачных проектов! Будем рады подписке и комментариям.

#itпродукты #itprojects #it #product #productmanagement #design #productdevelopment #development #developer