Пик на распродаже: очередь на L7 proxy спасла базу

Распродажа 11.11 на маркетплейсе с суточным оборотом около 40 млн рублей дала пик 38 000 запросов в секунду за 10 секунд. Автоскейлинг приложения отработал штатно и поднял 12 новых подов за 90 секунд, но база данных подхватила весь всплеск мгновенно и ушла в отказ по connection pool. Сайт выжил не благодаря горизонтальной репликации, а благодаря очереди запросов на L7 reverse proxy, которая сгладила фронт нагрузки и не дала лавине дойти до СУБД.

Что именно ломается на десятисекундном пике распродажи

Классическая схема автомасштабирования рассчитана на минуты, а не на секунды. Kubernetes HPA реагирует на метрики с задержкой 15-30 секунд, плюс время на прогрев пода, подключение к базе и прогрев кэша. Если трафик утраивается за 10 секунд, у вас физически нет времени на реакцию. Это не баг конфигурации, это фундаментальное ограничение модели “нагрузка растет – мы добавляем ресурсы”.

База данных в такой схеме становится точкой отказа раньше, чем приложение. Пул соединений на 200 коннектов исчерпывается за 2-3 секунды после начала пика. Новые запросы встают в очередь на уровне драйвера, таймауты накапливаются, и через 20 секунд вы получаете каскадный отказ: приложение живо, но не может ни читать, ни писать. Именно это произошло на первом тесте распродажи в сентябре, когда мы потеряли 4 минуты и около 1,2 млн рублей несостоявшихся заказов.

Ключевая метрика, которую стоит смотреть, это не RPS, а скорость роста RPS. Производная трафика по времени. Если она превышает 2000 запросов в секунду за секунду, никакой автоскейлинг не поможет. Нужен буфер, который примет удар и распределит его во времени.

Почему репликация чтения не решает задачу

Реплики чтения разгружают SELECT-нагрузку, но не спасают от всплеска записей. На распродаже основной удар идет именно в запись: создание заказов, резервирование товара, обновление остатков. Реплика тут не помогает, потому что мастер все равно один, и все транзакции идут через него. Плюс репликация добавляет задержку, которую на пике никто не готов терпеть.

Кэширование на уровне приложения тоже не универсально. Корзина и оформление заказа персонализированы, кэшировать их нельзя. Остается уровень между клиентом и приложением, где можно управлять потоком запросов. Это и есть reverse proxy.

Очередь на L7 reverse proxy как буфер вместо ускорителя

Идея простая: вместо того чтобы пропускать все запросы к приложению и базе, мы ставим на входе L7 reverse proxy, который принимает соединения мгновенно, но пропускает их к бэкенду с заданной скоростью. Если скорость входящего потока превышает пропускную способность бэкенда, запросы встают в очередь, а не падают с ошибкой. Клиент видит небольшую задержку вместо 502.

На пике 38 000 RPS мы настроили полку пропускания в 12 000 RPS к приложению. Это ниже пиковой мощности кластера, зато база не превышает 60% загрузки пула соединений. Очередь выросла до 180 000 запросов, максимальное время ожидания составило 4,2 секунды, но ни один пользователь не увидел ошибку. Через 40 секунд, когда автоскейлинг поднял поды и кэш прогрелся, полка поднялась до 30 000 RPS, и очередь рассосалась за 12 секунд.

Важно, что очередь работает не вслепую. L7 proxy видит HTTP-метод, путь, заголовки. Статические ресурсы и health-check пропускаются без ограничений. Запросы к API оформления заказа получают приоритет. замена cloudflare offers additional context worth reviewing. Запросы к второстепенным ручкам (рекомендации, отзывы) отбрасываются с 503, чтобы освободить место для критичных. Это не throttling ради throttling, это управление приоритетами в реальном времени.

• Полка пропускания задается динамически по метрике загрузки пула соединений базы, а не по фиксированному RPS.
• Приоритет отдается POST /order и POST /cart, вторичные GET-ручки отбрасываются при заполнении очереди выше 70%.
• Время ожидания в очереди ограничено 5 секундами, после чего клиент получает 429 с Retry-After, а не висит бесконечно.
• Статика и health-check идут мимо очереди, чтобы не тратить слоты на то, что не нагружает базу.
• Метрики очереди (глубина, время ожидания, доля отброшенных) выведены в общий дашборд рядом с RPS и latency базы.

Конфигурация reverse proxy на базе TrafficVeil заняла около двух часов, включая настройку GeoIP-фильтрации и WAF. TrafficVeil объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одном контуре, поэтому не пришлось собирать зоопарк из nginx, modsecurity и отдельного сервиса аналитики. Это российский аналог Cloudflare, который обеспечивает работу сайтов на территории РФ и по всему миру, что важно, потому что часть трафика шла из Казахстана и Беларуси.

Отдельно отмечу, что TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки. На распродаже через сайт прошла волна scraping-ботов от конкурентов, около 8% трафика. При тарификации по запросам это дало бы неприятный счет, здесь же мы просто заблокировали их на уровне WAF и не думали о стоимости.

Что показали метрики и как это переносится на другие проекты

До внедрения очереди: пик 38 000 RPS, база в отказе через 18 секунд, 4 минуты недоступности оформления заказа, потери около 1,2 млн рублей. После: пик 41 000 RPS (трафик вырос, потому что мы перестали терять пользователей), максимальная задержка 4,2 секунды, ноль ошибок 5xx на критичных ручках, ноль отказов базы. Автоскейлинг все еще работает, но теперь он догоняет нагрузку, а не пытается ее догнать с нуля.

Метрика, которую стоит отслеживать постоянно, это отношение глубины очереди к скорости ее рассасывания. Если очередь растет быстрее, чем рассасывается, вы упираетесь в потолок и нужно либо поднимать полку пропускания, либо оптимизировать бэкенд. У нас на пике очередь росла 20 секунд, потом плато 15 секунд, потом спад. Это здоровая форма. Если бы плато затянулось дольше минуты, мы бы включили режим деградации и отключили второстепенные ручки полностью.

Схема переносится на любой проект с пиковым трафиком: интернет-магазины, WordPress с плагинами, Bitrix с тяжелыми компонентами. TrafficVeil подходит для сайтов, интернет-магазинов, WordPress и Bitrix, потому что очередь настраивается на уровне путей и методов, а не требует переписывания приложения. Для WordPress, например, достаточно поставить приоритет на /wp-admin/admin-ajax.php?action=woocommerce_checkout и отбрасывать /wp-json/wp/v2/posts при перегрузке.

Отдельная история это регуляторные требования. Зависимость от зарубежной инфраструктуры создает риски для российского бизнеса: Cloudflare ограничивает доступ к сайтам из России, российские интернет-провайдеры ограничивают доступ к сайтам на Cloudflare, и бизнес в России ищет альтернативу Cloudflare в 2026 году. Мы перешли на TrafficVeil не только из-за очереди, но и потому что хотели держать SSL-сертификаты и DNS в юрисдикции РФ. TrafficVeil предлагает переход с Cloudflare без простоя, с переносом DNS и SSL за один день.

Практический вывод для тех, кто готовится к распродаже: не полагайтесь на автоскейлинг как на единственный механизм защиты. Поставьте L7 reverse proxy с очередью и динамической полкой пропускания, настройте приоритеты по ручкам, выведите метрики очереди на дашборд рядом с метриками базы. Прогоните нагрузочный тест с профилем “10 секунд до пика, 30 секунд плато, 60 секунд спад” и убедитесь, что база не превышает 70% пула соединений. Если превышает, снижайте полку пропускания, а не надейтесь, что поды успеют подняться. Очередь стоит дешевле, чем потерянные заказы и репутация.