Сегодня 11 ноября – день, когда трафик маркетплейса вырастает в разы за минуты. Распродажа обнажает каждое слабое место: медленный запрос к базе, незакэшированную карточку, платёжный шлюз, который не держит всплеск. Подготовку к этому пику начинают за месяцы, а не накануне. Разберём, что именно ломается под нагрузкой и как этого избежать.

Где система рвётся первой

Под пиковой нагрузкой падает не весь сайт, а конкретные узкие места. Чаще всего это база данных: длинные блокировки на таблице остатков, неоптимальные джойны в каталоге, отсутствие индексов на полях фильтрации. Второй кандидат – синхронные вызовы внешних сервисов. Когда оформление заказа дёргает платёжный шлюз, службу доставки и сервис лояльности в одном HTTP-запросе, любая задержка партнёра превращается в очередь зависших соединений и каскадный отказ.

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

Интеграции как точка отказа

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

Здесь спасают три приёма. Первый – таймауты и circuit breaker на каждом внешнем вызове: если партнёр не отвечает за условные 800 мс, запрос разрывается, а не копит соединения. Второй – идемпотентность платёжных и заказных операций, чтобы повторная отправка после таймаута не списала деньги дважды. Третий – деградация вместо отказа: при недоступности рекомендательного сервиса покажите статичную выдачу, при сбое расчёта доставки – диапазон вместо точной цены. Под нагрузкой устойчивость этих контуров держится не на коде, а на согласованных контрактах интеграции между разнородными системами: таймауты, формат ошибок и гарантии доставки должны быть зафиксированы между всеми командами и подрядчиками заранее.

Регуляторный фон тоже давит. Требования 54-ФЗ к онлайн-кассам и фискализации никуда не делись: чек должен уйти ОФД даже под пиковой нагрузкой, и очередь чеков нельзя терять при перезапуске. Импортозамещение добавляет ограничений на выбор СУБД и middleware – мы подробно разбирали текущий статус перехода на отечественный стек, и при проектировании нагрузочного контура это влияет на лицензии и доступную экспертизу.

Что делать за месяц до пика

Подготовка к распродаже – это чеклист, а не героизм в ночь акции. Зафиксируйте бюджет ошибок и пороги автомасштабирования. Прогоните нагрузочные тесты с реальными сценариями: вход, поиск, добавление в корзину, оформление, оплата. Настройте мониторинг по бизнес-метрикам, а не только по CPU: конверсия оформления, доля успешных платежей, время отдачи карточки. Подготовьте план отката и режим «только чтение» каталога на крайний случай.

Команда должна заранее распределить дежурства и иметь под рукой runbook на типовые инциденты. Хайповые технологии вроде генеративных моделей здесь не помогают – мы недавно трезво оценивали их раннюю зрелость. А вот налоговый и кадровый контекст ИТ-команд стоит учитывать при планировании ресурсов: льготы и нагрузка на разработку меняются, и мы фиксировали это в полугодовом обзоре налогового манёвра.

Вывод

Пиковая нагрузка не прощает импровизации. Маркетплейс держит 11.11 не за счёт мощного железа в последний момент, а благодаря асинхронной архитектуре, защищённым интеграциям и отрепетированному сценарию отказов. Готовьте инфраструктуру заранее – распродажа лишь проверяет то, что вы заложили месяцами ранее.