Юркас
Год развиваем e-com-ядро Yurkas. Продажи не останавливались ни на день
о проекте
Год развиваем e-com-ядро Yurkas. Продажи не останавливались ни на день
описание
Для Yurkas, белорусской розничной сети дверей и материалов, мы переписываем ядро конфигуратора товаров со сложной доменной логикой. Новая архитектура растёт параллельно с действующей системой — продукт продолжает приносить выручку.
стек технологий
PHP / Symfony / Nuxt / RabbitMQ / PostgreSQL
время разработки
За год работы команда переписала ядро конфигуратора Yurkas на новую архитектуру, перенесла около половины ключевых страниц, вывела тяжёлые операции в асинхронную обработку и уложила потребление ресурсов в десятки раз меньше прежнего.
Бизнес не заметил, что у него меняют ядро
Развивать критичный для бизнеса продукт без права на остановку
К нам пришла не новая разработка, а живая e-commerce-система с накопленным наследием — и с дневной выручкой, которую нельзя поставить на паузу.
[ Запрос ]
Развивать и стабилизировать конфигуратор товаров — модуль, через который Yurkas продаёт двери, фурнитуру и сопутствующие материалы. У клиента нет собственной команды разработки. Проект пришёл с накопленным наследием от предыдущих этапов работы — со сложной доменной логикой и техническим долгом, который мешал развитию.
[ Вызов ]
Сделать это, не остановив продажи. Доменная модель сильно связана: один атрибут влияет на номенклатуру, фильтры, совместимость, цены и внешние интеграции. Ежеминутно пересчитываются миллионы товарных моделей. Цена ошибки в этой системе исчисляется миллионами.
способ решения задачи
Можно было переписать с нуля. Мы выбрали путь сложнее, но безопаснее для бизнеса
Путь 1
Переписать с нуля
Привычное решение для систем с накопленным техдолгом. Звучит быстрее на бумаге. На практике это означает остановку работающего конфигуратора на время миграции — потерю продаж, операционный простой, риск, что миграция данных пойдёт не так. Для системы, через которую идёт ежедневная выручка, это слишком дорогой эксперимент.
Путь 2
развивать рядом — [ наш выбор ]
Новая архитектура строится параллельно с действующей системой. Старый конфигуратор продолжает продавать, пока команда переносит модули по одному. Каждый перенос — отдельный управляемый шаг с возможностью отката. Это медленнее на бумаге, но единственный путь для продукта, у которого нет права на остановку.
Сделать быстро — задача подрядчика. Не уронить бизнес — задача партнёра
[ Подход ]
Старая система продаёт Новая — растёт рядом
Сохраняем то, что работает
Действующий конфигуратор остаётся источником продаж до тех пор, пока новая версия не закроет его функциональность полностью. Не трогаем то, что прямо сейчас приносит выручку клиенту.
Строим новое рядом
Каждая бизнес-область — каталог, цены, комплекты, интеграции — живёт в своём изолированном пространстве со своими правилами. Связи между ними становятся явными.
Переносим по одной странице
Каждый перенос — отдельный управляемый шаг. Сначала готовим новую версию модуля, тестируем её рядом со старой, потом переключаем трафик. В любой момент можно откатиться.
Развиваем параллельно
Пока идёт миграция, продукт продолжает развиваться: добавляются новые правила ценообразования, сценарии, интеграции. Новая архитектура изначально проектируется под то, чтобы вмещать развитие.
Этот подход выдерживает даже паузы в коммуникации, естественные для компаний без внутренней команды разработки Бизнес продолжает работать, а команда — двигаться вперёд по своему графику
Архитектура, которая выдержит развитие
Новая архитектура проектируется под то, чтобы прожить столько, сколько потребуется продукту, и принимать в себя новые правила без структурной перестройки
domain-driven design
Бизнес-логика вынесена в доменные модули с чёткими границами. Изменение правила в одном месте больше не означает риск для десятков смежных компонентов.
Что это даёт:
— Новый функционал добавляется внутрь одного модуля, а не размазывается по всей системе.
— Связи между доменами становятся явными и управляемыми.
— Команда видит, где заканчивается одна предметная зона и начинается другая.
асинхронные очереди
Тяжёлые операции — массовый пересчёт цен, генерация номенклатуры, синхронизация — выведены в фоновую обработку через RabbitMQ. Пользовательские сценарии больше не блокируются.
Что это даёт:
— Покупатель не ждёт, пока система пересчитывает то, что должна была посчитать ночью.
— Тяжёлые задачи запускаются в рабочие часы без риска положить систему.
— Можно горизонтально масштабировать обработку без переделки кода.
наблюдаемость и аудит
С нуля разработана страница системных уведомлений. Введены роли админов и суперадминов. Команда клиента видит, что происходит внутри системы, и может вмешаться до того, как ошибка дойдёт до покупателя.
Что это даёт:
— Любое подозрительное событие фиксируется и проверяется.
— Изменения в критичных зонах (цены, совместимость, номенклатура) контролируются.
— Снижается риск того, что ошибка станет видна только из жалобы клиента.
управляемая миграция
Каждый перенос модуля начинается с того, что новая версия поднимается рядом со старой и тестируется на реальном трафике без переключения. Только после того, как она показывает себя стабильно, на неё переводится поток. Старая система остаётся горячим резервом — на случай неожиданного поведения новой.
Что это даёт:
— Команда видит поведение новой версии в реальных условиях до того, как она становится боевой.
— Изменения происходят постепенно, без эффекта «большого взрыва».
— Команда клиента может проверять каждый перенос до того, как он станет необратимым.
Стек: PHP / Symfony / Nuxt / RabbitMQ / PostgreSQL
Современный, проверенный стек, подходящий для долгого развития. Без экспериментальных решений — где работает бизнес клиента, нет места для технологических ставок.
Проект в цифрах
Что изменилось в системе после миграции на новую архитектуру и переработки самых тяжёлых операций
50 ГБ
→2 ГБ
[Память воркеров RabbitMQ]
Устранены десятки утечек памяти, накопленных за историю проекта
2 часа
→15 секунд
[Тяжёлые запросы]
После перехода на контейнеризацию и оптимизации обработки
в 3–9 раз быстрее
[Скорость API]
По разным эндпоинтам — в зависимости от типа операции
более 4 ГБ
→20 МБ
[Память на отдельных запросах]
На самых тяжёлых операциях пересчёта
Польза
Что это значит для бизнеса
Эффективность
Та же инфраструктура держит больше — система не упирается в железо по мере роста.
Оптимизация
Сценарии, которые раньше нельзя было запускать в рабочие часы, теперь идут в фоновом режиме за секунды.
Готовность к росту
Запас прочности для роста бизнеса — архитектура выдержит больше товаров, цен, заказов без необходимости снова трогать ядро.
Что сделано
Основная работа шла над ядром конфигуратора. Параллельно команда закрывала смежные технические задачи — там, где у клиента не было других подрядчиков.
[ 1 ] Ядро системы
Половина ключевых страниц переведена со старой версии на новую архитектуру. Работа продолжается — оставшиеся переносятся поэтапно, с переключением трафика только после прохождения проверок.
Массовый пересчёт цен, генерация номенклатуры и синхронизация с внешним учётом выведены в очереди RabbitMQ. Поддержаны сценарии расчёта будущих цен и массовая фоновая обработка товарных позиций.
[ 2 ] Управление и наблюдаемость
Разработана с нуля. Фиксирует критичные события и нештатные сценарии — операторы видят их раньше, чем они доходят до покупателя. Заменяет жалобу клиента как способ узнать о проблеме.
Введены роли админов и суперадминов с разделением прав. Изменения в критичных зонах системы — ценах, совместимости, номенклатуре — требуют соответствующих полномочий.
[ 3 ] Смежные интеграции
Реализована единая авторизация через OAuth2: синхронизация ролей, управление папками, автоматический выход при смене пароля. Передана техническая документация для администраторов.
AI-помощник в Telegram для поиска по номенклатуре Бот на базе LLM помогает менеджерам и клиентам находить товары в каталоге на естественном языке — без точных артикулов. Понимает синонимы, нестрогие запросы, уточнения в диалоге. Точность поиска около 90%
[хотите так же?]
Развиваем продукты, которые нельзя выключить
У вас есть e-commerce-система или продуктовая платформа, которая приносит выручку — но требует развития, стабилизации или смены архитектуры? Разберём задачу и предложим инженерно безопасный путь без даунтайма и без перезапуска.
