Прямые эфиры

Прямые эфиры с микросервисной архитектурой

Moymir.ru — eCommerce с live-продажами. В прямых эфирах товары получают спецусловия и скидки. Для каждого эфира формируется уникальный акционный ассортимент.

О проекте

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

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

Это так же требовало реализации логики активации и деактивации скидок в заданные временные интервалы
Особое внимание уделялось требованиям к поведению сайта с учётом целевой аудитории — пользователи старше 55 лет, со средним временем оформления заказа в 60–80 минут.

Это накладывает серьёзные ограничения на сохранение контекста сессии, стабильность отображения корзины и информации о скидках, а также требует проработки сценариев возврата на сайт без потери состояния заказа.
СПЕЦИАЛИСТЫ ПРОЕКТА
1 Frontend
|
3 Backend
|
1 PM
|
1 QA
СТЕК ТЕХНОЛОГИЙ
Pimcore
Redis
Laravel
PostgreSQL
React
Moonshine
Задачи
Повышение конверсии и улучшение
пользовательского опыта
Настроить логику вывода товаров и применения скидок во время эфира
Обеспечить стабильную работу под высокой нагрузкой
Корректность остатков, цен и заказов
Повышение вовлечённости и удобства покупок
Решение
Сокращение неопределённостей: системная работа с рисками
Синхронизация скидок и акций в реальном времени
Ресайзер WebP, оптимизация фронта и облако
Частая синхронизация и проверка перед оформлением
Прямые эфиры, подборки товаров и видимые остатки
Никита
Технический директор Alto
Ключевой особенностью проекта было то, что мы  разрабатывали  с нуля решения и встраивались в уже существующую инфраструктуру  клиента: с собственной мастер-системой, внешними интеграциями и специфичной логикой прямых эфиров.

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

Ведение проекта

Выявили и проработали риски по всем направлениям:
Интеграционные (Retail Rocket, прямые эфиры, ЮKassa, поиск, доставка)
Управленческие (согласование между командами, смена PM, отсутствие доступов)
Технические (нагрузка, сбои, частичная готовность стороннего фронта)
Внутренние (ресурсы команды, замены, ключевые роли)
Системные (очереди, очередность релизов, взаимодействие с внешними API).

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

Аналитика

Задача данного этапа была зафиксировать и провалидировать требования, разработать архитектурное решение, которое эффективно встроится в уже работающую ИТ-инфраструктуру.
Что мы сделали:
Провели ряд интервью с командой заказчика, чтобы понять ограничения, технические допущения и специфику их внутренних процессов;
Задокументировали требования, а также разработали и согласовали архитектурные решения, основанные на этих требованиях
Проработали схему интеграции с инфраструктурой клиента, в которой уже хранились данные о товарах, скидках, эфирах и статусах. Договорились о модели взаимодействия: кто в каком случае является инициатором, и о структуре передаваемых данных.
На основе анализа мы составили техническое задание, разбили его на задачи и визуализировали сроки в диаграмме Ганта.

Диаграмма Ганта сразу подсветила контрольные точки, ключевые этапы и промежуточные дедлайны. Благодаря этому мы постоянно контролировали прогресс и оперативно корректировали план - перераспределяли задачи, добавляли ресурсы и следили за приоритетами.
Детали разработки

Работа с учётом ограничений

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

Разработку бэкенда каталога и товаров начали на старте проекта с минимального набора задач, что позволило быстро получить наработки для административной панели. Через месяц передали первый рабочий релиз с функциональностью обогащения номенклатуры.
Отдельным приоритетом стало внедрение сервиса очередей для интеграции с маркетинговой системой. Его заблаговременный запуск обеспечил стабильность и бессбойный релиз.
Параллельно реализовали кастомные интерфейсы для панели, так как MoonShine не давала нужного функционала. Ранний запуск модулей позволил плавно внедрить DevOps-процессы без перегрузок на финальном этапе.
детали проекта

Как мы реализовали проект

Интеграция с мастер-системой

Несмотря на наличие API со стороны мастер-системы, основной вызов заключался не в технической интеграции, а в корректной обработке и обогащении полученных данных.

API предоставлял лишь базовую информацию по товарам — артикул, название, остаток, цену и ключевые опции. Для полноценного отображения на витрине требовалось дополнение: описания, изображения, SEO-поля, уточнённые характеристики.

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

Это решение позволило исключить несоответствующие поля (например, размер обуви у платья), одновременно упростив построение фильтров на фронте.

Категории также синхронизировались из мастер-системы, но обогащались дополнительными данными - изображениями, SEO-настройками и текстами.

Виртуальные категории

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

Они имплементировали поведение стандартной категории, но не нарушали структуру каталога — решение было особенно полезно для промо-блоков и спецразделов.

Чтобы поддерживать точные остатки товаров на витрине, мы ещё на этапе аналитики разработали гибкую схему синхронизации.

Часто меняющиеся товары (например, популярные позиции или товары в эфирах) обновляются чаще, менее приоритетные — реже. За счёт этого мы добились актуальности информации для пользователя без избыточной нагрузки на мастер-систему.

Такое решение позволило сохранить стабильную работу всей системы даже при росте трафика.

Интеграция с Retail Rocket: отказ от фидов в пользу событийной модели

Большинство eCommerce-платформ интегрируются с Retail Rocket через XML-фиды. Это просто, но даёт значительную задержку при передаче данных — если ассортимент и доступность меняется часто во время  flash-распродаж, прямых эфиров и в коротких промо-окнах.

Мы не нашли подтверждений, что такой способ интеграции обеспечит нужную скорость передачи изменений в Retail Rocket для прямых эфиров. Поэтому пошли путем API-интеграции.
Что мы сделали:
Вместо фидов реализовали событийную модель интеграции через очереди
Мы сделали так, что любое изменение (цена, остаток, публикация товара, привязка к эфиру) моментально уходит в очередь, а оттуда выполняется запрос к Retail Rocket

Очереди и API: мгновенное обновление ассортимента без потери производительности

Благодаря использованию очередей синхронизация с Retail Rocket не отражается на производительности витрины, т.к. происходит в отдельном масштабируемом сервисе очередей
Мы встроились в цепочку передачи данных так, чтобы eCommerce-процессы не подстраивались под возможности инструмента, а наоборот — инструмент подстроили под реальную бизнес-логику клиента.
Что это даёт бизнесу:
Увеличение конверсии в пиковые моменты
Меньше ошибок и расхождений в аналитике
Более точная персонализация — данные о товарах в Retail Rocket всегда актуальны
Почему это важно:
В рамках прямых эфиров есть жёсткая логика: товар должен появиться в определённое время, с нужной ценой и скидкой
Даже 5-10 минут задержки из-за фида — это потерянные продажи либо товар, попадающий в предложения пользователю, который по факту уже закончился
Благодаря очередям и API-интеграции система реагирует в реальном времени: что на эфире, то и на сайте
Сделали сервис ресайзинга изображений для товаров на Node.js
Наша разработка создает уменьшенные и оптимизированные версии изображений в формате WebP, что ускоряет загрузку страниц на 30%. Режим прогрева кэша позволяет менять настройки размеров и сразу генерировать новые версии по запросу, а уже созданные файлы отдаёт Nginx.

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

Опыт работы с eCommerce-системами позволил быстро адаптировать и интегрировать сервис, сократив сроки разработки и повысив надёжность.
А также, передали готовый проект клиенту, как итоговый вариант
С учётом сложности архитектуры, интеграций и бизнес-логики поддержку проекта передали штатному разработчику заказчика.

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

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

Ключевые особенности и их значение

Прямые эфиры доступны для просмотра прямо на сайте

Крупный баннер и кнопка «Смотреть» на главной странице. Рядом с видео отображается подборка товаров из эфира, которые можно сразу приобрести со скидкой.

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

Карточка товара

Реализовали карточку товара с фиксированной основной информацией — цена, описание и характеристики остаются на месте при прокрутке.

При скролле динамически меняются фотографии товара, сохраняя фокус на визуальном контенте.

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

Отображение остатков

Отображение остатков реализовали на уровне фронтенда с поддержкой бизнес-логики, получаемой из API склада.

При загрузке данных проверяется количество товара на складе: если запас больше 20 — выводится статус
«В наличии», при количестве от 10 до 20 показывается статус «Мало», а если осталось меньше 10 единиц — отображается точное число.

Функция «Поделиться»

В карточке товара реализована кнопка «Поделиться», которая позволяет скопировать ссылку на товар или сразу выбрать один из популярных каналов — Telegram, ВКонтакте и Одноклассники.

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

Итоги проекта

Бизнесовые результаты

Повышена производительность, стабильность и корректность данных: цен, скидок и трансляций. Что улучшило пользовательский опыт.

Новый стек технологий ускорил выпуск обновлений, масштабирование и поддержку новых форматов продаж.

Архитектура и инфраструктура

Проект перешёл с монолитной архитектуры на распределённую.

Фронтенд выделен в отдельное приложение на Next.js, а инфраструктура перенесена в облако, что повысило стабильность и скорость отклика.

Техническая трансформация

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

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

Команда

Роман Т.
Менеджер проекта
Никита Б.
Технический директор
Николай П.
Backend-разработчик
Иван И.
Backend-разработчик
Артур Ш.
QA
Backend-разработчик
Антон Ч.
Frontend-разработчик
Никита Щ.