Рассылка приводит покупателей на сайт, но вместо роста заказов бизнес получает недоступный каталог. В предыдущих акциях интернет-магазина сайт падал примерно после отправки 30% рассылки.
К новой распродаже требовалось подготовить сайт к массовому приходу посетителей. При этом основная система, от которой зависела работа магазина, оставалась прежней: её замена уже разрабатывалась, но ждать окончания большого проекта бизнес не мог.
Команда OpenStart подготовила промежуточное решение: кеширование товаров, прогрев данных и оптимизацию каталога. Распродажа с общей аудиторией email-рассылки и push-уведомлений 400 000 пользователей впервые прошла без падения сайта.
Почему нагрузку не выдерживала внешняя система
В обычном режиме сайт при каждом обращении запрашивал данные по REST API — программному интерфейсу внешней системы. В ней хранились товары, остатки, информация о заказах и другие данные, необходимые магазину.
Такая схема делала сайт зависимым не только от собственных ресурсов. Когда после рассылки посетители одновременно приходили в каталог, росло число запросов к внешней системе. Именно такой поток обращений она не выдерживала.
Поэтому задача не сводилась к ускорению отдельных страниц. Нужно было сократить количество обращений к ограниченному источнику данных, сохранив возможность обновлять каталог во время продаж.
Стек проекта: Node.js, NestJS, React, PostgreSQL, Redis и Elasticsearch.
Почему не стали ждать новую систему
Параллельно мы разрабатываем систему, которая должна полностью заменить старую. Но это отдельный сложный проект, а у распродажи были свои сроки.
Нужен был способ провести ближайшую акцию на существующей архитектуре — без ожидания полной замены и без попытки выдать временное решение за завершённую модернизацию.
Мы сосредоточились на пути покупателя по каталогу: данных товаров, составе категорий и поиске. Их подготовка заранее позволяла уменьшить зависимость сайта от прямых обращений к старой системе в момент наплыва посетителей.
Что изменили перед распродажей
Подготовили кеш товаров в Redis
Данные товаров хранили в кеше Redis, чтобы снизить потребность в повторных обращениях к внешней системе при работе с каталогом.
Это было особенно важно в начале акции: email-рассылка и push-уведомления шли одновременно, а основной пик нагрузки пришёлся на первый час.
Подготовили категории и поиск в Elasticsearch
Состав категорий и поиск по каталогу обслуживались через Elasticsearch. Кеш товаров и данные каталога прогревали перед акцией, чтобы не оставлять их подготовку на момент, когда на сайт уже пришли покупатели.
Redis и Elasticsearch выполняли разные задачи: первый хранил кеш товаров, второй — состав категорий и обеспечивал поиск.
Учли изменения во время акции
Сохранить данные один раз перед стартом было недостаточно. Во время распродажи менялись остатки: товары покупали, и каталог должен был учитывать эти изменения.
Дополнительную сложность создавал ранний доступ. Он зависел от принадлежности покупателя к сегменту в системе сегментации аудитории. Сегменты также менялись во время акции.
Поэтому обновление данных учитывало и изменение остатков, и изменение сегментов раннего доступа. Кеширование должно было снижать нагрузку, а не превращать каталог в неизменную копию состояния на момент старта.
Как прошла акция
Работу системы отслеживали в реальном времени через GMonit и Grafana. Пиковая нагрузка наблюдалась в начале распродажи:
- около 1 100 посетителей в минуту;
- около 9 500 просмотров в минуту;
- более 100 заказов с онлайн-оплатой за первый час.
Это показатели реальной акции, а не нагрузочного теста. Посетители и просмотры в минуту не означают такое же количество одновременных пользователей или серверных запросов в секунду.
Главный результат для бизнеса — рассылка прошла, сайт не упал, покупатели смогли оформлять и оплачивать заказы. В отличие от предыдущих акций, сбой не остановил работу магазина примерно на первой трети отправки.
Что решено, а что остаётся отдельной задачей
Подготовка позволила провести конкретную распродажу, не дожидаясь замены основной системы. Но успешная акция не означает, что у старой системы исчезли все ограничения или что сайт теперь выдержит любой объём трафика.
Её замена продолжает разрабатываться. Более высокая производительность — цель нового решения, а не результат, который мы уже измерили и можем приписать этому кейсу.
Здесь был другой результат: дать бизнесу провести запланированную акцию на действующей инфраструктуре, снизив влияние её известного ограничения.
Что проверить перед массовой рассылкой
Если сайт уже падал во время акций, начинать стоит не с выбора более мощного сервера, а с нескольких вопросов:
- От каких внешних систем зависит открытие каталога? Запрос посетителя может запускать цепочку обращений, и ограничение окажется за пределами сайта.
- Какие данные можно подготовить заранее? Прогрев помогает не переносить всю подготовительную работу на первые минуты акции.
- Что должно обновляться во время продаж? Остатки, доступ к предложениям и другие изменяющиеся данные требуют отдельных правил обновления.
- Как будете оценивать результат? Доступная главная страница ещё не подтверждает, что покупатель может найти товар, оформить и оплатить заказ.
Временное решение имеет смысл, когда понятны его задача и границы. В этом проекте оно помогло провести распродажу сейчас, пока команда работает над долгосрочной заменой системы.
Готовите акцию и сомневаетесь, выдержит ли сайт?
Обсудите подготовку с OpenStart. Начать можно с описания прошлых сбоев, схемы интеграций и доступных графиков нагрузки — это поможет определить, какие участки нужно проверить перед рассылкой и какие изменения имеют смысл до ближайшей акции.