Как Vpodarok прошёл путь от монолита на Yii1 до сервисной архитектуры с собственным процессингом

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

Как всё начиналось: монолит, который стал ERP.

Первые версии Vpodarok были написаны на Yii1. Это был классический интернет-магазин: выбрать сертификат, оформить заказ, отправить на почту.

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

- появлялись витрины под B2B-клиентов;

- добавлялись функции для юрлиц и отчётность;

- росли API и интеграции с 1С;

- появилась генерация PDF и партнёрские рассылки.

Наша команда приняла проект и параллельно поддержки старого решения строила новый проект на фреймворке Laravel. Позже был произведён плавный переход на новое решение и отказ от старого.

Время шло, новое приложение так же обрастало функционалом. На проекте участвовало несколько команд включая нашу.

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 стал не стихийной перепиской, а планомерной эволюцией, продиктованной требованиями бизнеса.

Архитектура изменилась, потому что продукт вышел за рамки одной витрины и стал платформой. Теперь система готова к росту, масштабированию и внедрению новых решений без страха «сломать всё».

И хотя путь занял не один год, он стал основой для устойчивого развития продукта в долгую.

Желаем всем удачных проектов! Будем рады подписке и комментариям.