Как подготовить веб-приложение к резкому росту трафика

Короткий ответ

Пик трафика ломает не «сервер вообще», а одно конкретное узкое место — чаще всего базу данных, внешний API или медленный эндпоинт. Поэтому подготовка идёт в таком порядке:

1. Измерить: нагрузочный тест на реалистичном сценарии.
2. Разгрузить базу: кэш и пул соединений.
3. Убрать тяжёлую работу из запроса: очереди.
4. Дать системе расти: горизонтальное масштабирование и автоскейлинг.
5. Решить, что отключить при перегрузке: graceful degradation.

Шаг 1. Найдите узкое место

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

• Запустите нагрузочный тест (k6, Locust, JMeter) на стейджинге, максимально похожем на прод.
• Повышайте нагрузку ступенями и смотрите, где первым растёт время ответа.
• Параллельно следите за метриками: CPU, память, число соединений к БД, медленные запросы, ошибки 5xx.

Типичные находки: запрос без индекса, N+1 запросы в ORM, синхронный вызов платёжного или SMS-шлюза, генерация PDF прямо в обработчике.

Шаг 2. Кэшируйте всё, что можно

Кэш — самый дешёвый способ выдержать пик.

Важно продумать инвалидацию: при изменении цены или остатка кэш должен обновиться. Для каталога часто хватает короткого TTL — даже несколько секунд кэша снимают огромную долю одинаковых запросов.

Защититесь от cache stampede: когда ключ истекает, сотни запросов одновременно идут в базу. Помогают блокировка на пересчёт или обновление кэша в фоне до истечения.

Шаг 3. Пул соединений к базе

Каждое новое соединение с PostgreSQL или MySQL стоит ресурсов, а их лимит конечен. Если вы масштабируете приложение до десятков инстансов, каждый со своим пулом, база упрётся в лимит соединений раньше, чем в CPU.

• Настройте пул в приложении с разумным максимумом на инстанс.
• Для PostgreSQL рассмотрите PgBouncer как общий пулер.
• Вынесите тяжёлые отчёты на read-реплику.

Шаг 4. Очереди для тяжёлой работы

Пользователь не должен ждать, пока отправится письмо или сформируется счёт. Запрос делает минимум (сохраняет заказ) и ставит задачу в очередь, а воркеры обрабатывают её отдельно.

Запрос -> сохранить заказ -> поставить задачу -> ответ 200
                                   |
                         Воркеры: письмо, SMS, 1C, PDF

Подходят RabbitMQ, Redis-очереди, Kafka или облачные сервисы. Плюс: при пике очередь просто растёт, а не роняет сайт. Число воркеров можно масштабировать отдельно.

Шаг 5. Горизонтальное масштабирование и автоскейлинг

Чтобы добавлять инстансы, приложение должно быть stateless: сессии в Redis или токенах, файлы в объектном хранилище, а не на локальном диске.

• Балансировщик распределяет трафик между инстансами.
• Автоскейлинг (например, HPA в Kubernetes) добавляет поды по CPU или числу запросов.
• Учтите время старта: новые инстансы поднимаются не мгновенно. Перед запланированной акцией увеличьте минимум заранее, а не надейтесь на реакцию автоскейлера.

Шаг 6. Graceful degradation

Решите заранее, чем можно пожертвовать, чтобы ядро (каталог, корзина, оплата) работало:

• отключить рекомендации, поиск по отзывам, живые счётчики;
• показывать кэшированную версию страницы при ошибке бэкенда;
• ввести rate limiting для ботов и тяжёлых эндпоинтов;
• использовать circuit breaker для внешних API, чтобы зависший сервис не держал потоки;
• при крайней перегрузке — страница ожидания вместо ошибки 502.

Сделайте эти переключатели feature flags, чтобы включать их без деплоя.

Чек-лист перед акцией

• Нагрузочный тест пройден с запасом выше ожидаемого пика.
• Дашборды и алерты настроены, дежурный назначен.
• Минимальное число инстансов поднято заранее.
• Заморожены деплои на время пика.
• Лимиты внешних сервисов (платёжки, SMS) уточнены.
• Есть план отката и список флагов для отключения функций.

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

• Масштабировать приложение, когда упирается база.
• Тестировать на пустой базе с парой товаров.
• Забыть про лимиты сторонних API.
• Выкатывать новый релиз в день распродажи.