Подготовка интернет-магазина к распродажам: нагрузка, остатки, оплата

Что сделать до распродажи

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

1. Определить ожидаемый пик по прошлым акциям и маркетинговому плану.
2. Провести нагрузочное тестирование сценариев покупки, а не только главной страницы.
3. Вынести чтение каталога в кэш и CDN.
4. Защитить чекаут очередью и лимитами.
5. Сделать резервирование остатков устойчивым к конкуренции.
6. Согласовать лимиты с платёжными провайдерами и подготовить запасной сценарий.
7. Ввести code freeze и собрать war room на время акции.

Нагрузочное тестирование

Тестируйте пользовательские сценарии целиком: вход, поиск, карточка товара, корзина, оформление, оплата в тестовом режиме. Инструменты вроде k6, Gatling или Locust позволяют описать такой путь.

На что смотреть:

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

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

Кэш и разгрузка каталога

Большая часть трафика — это просмотры. Чем меньше запросов доходит до базы, тем больше ресурсов остаётся чекауту.

• Статика и картинки — через CDN.
• Страницы каталога — кэш с коротким TTL или фоновой ревалидацией.
• Остатки на витрине показывайте приблизительно («мало», «в наличии»), а точную проверку делайте при оформлении.
• Прогрейте кэш перед стартом акции, чтобы первая волна не ударила в базу.

Очередь на чекауте

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

Остатки при конкуренции

Главный риск — oversell: два покупателя оплатили последнюю единицу. Решения:

• атомарное списание одним запросом с условием;
• резерв с таймаутом на время оплаты и освобождение при отказе;
• отдельный счётчик для горячих товаров в Redis с последующей сверкой.

UPDATE stock
SET reserved = reserved + 1
WHERE sku = $1 AND quantity - reserved >= 1;
-- 0 обновлённых строк = товара нет

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

Оплата и запасные сценарии

• Уточните у провайдеров (Payme, Click, Stripe и др.) лимиты запросов и предупредите о пике.
• Настройте таймауты и повторы с идемпотентным ключом, чтобы повтор не создал двойное списание.
• Подготовьте fallback: второй платёжный метод, оплату при получении, сохранение заказа с оплатой позже.
• Обрабатывайте вебхуки через очередь и сверяйте статусы, если вебхук задержался.

War room и мониторинг

На время акции нужна команда с понятными ролями и единым каналом связи.

Заранее пропишите runbook: кто принимает решение, как отключить тяжёлые функции (рекомендации, персонализацию), как переключить провайдера и как откатить релиз.

Частые ошибки

• Выкатывать новые функции за день до акции.
• Тестировать только главную страницу.
• Забыть про внешние системы — CRM, 1С, SMS-шлюз тоже имеют лимиты.
• Не предупредить службу поддержки и склад о масштабе акции.