API без ограничений нагрузки: чем это грозит и что делать

В пик распродажи сайт открывается через раз. Мониторинг показывает шквал запросов не от посетителей витрины, а от одного партнёрского ключа: интеграция партнёра ушла в цикл и долбит ваш API тысячами вызовов в минуту. Квот нет. Приоритетов нет. Backend честно пытается обслужить всех — и падает для всех, включая кассу, личный кабинет и мобильное приложение.

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

Разберём, как это проявляется, какие ошибки закрепляют хаос и как выстроить лимиты так, чтобы API оставался полезным для интеграторов и безопасным для выручки.

Когда один ключ роняет весь контур

Партнёрская витрина или мобильное приложение зациклилось на повторных запросах каталога. Без потолка по ключу нагрузка растёт линейно, пока не упрётся в CPU, пул соединений к БД или лимиты шлюза. Пользователи видят таймауты, поддержка — лавину жалоб, маркетинг — сорванную акцию.

Внутренний сервис отчётов ночью выгружает «все заказы за год» пачкой без пагинации и без отдельного лимита. Днём этот же API обслуживает онлайн оплату. Утром платежи тормозят, хотя «ночью же всё было тихо». Конкуренция за общий ресурс без политики потребления заканчивается одинаково плохо для всех потребителей.

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

Почему лимиты «потом» обычно не появляются

На старте API делают «чтобы заработало». Авторизация есть, документация кое-как есть, а политика потребления откладывается. Пока клиентов мало, система терпит. Когда появляется успешный партнёр или агрессивный клиент — терпеть перестаёт сразу и публично.

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

Третья — путать защиту от внешнего DDoS с контролем своих же интеграций. WAF и CDN полезны, но не заменяют квоты на API ключ, партнёра и метод. Внутренний шторм с валидной авторизацией часто проходит туда, куда внешнего бота не пускают.

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

Пятая ошибка — считать, что «у нас же авторизация, значит всё под контролем». Авторизация отвечает на вопрос «кто ты». Rate limit отвечает на вопрос «сколько тебе можно». Без второго ответа первый лишь открывает дверь в общий ресурс без дозирования.

Как внедрить-rate-limits-без остановки бизнеса

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

Разделите лимиты по слоям: на ключ, на партнёра или организацию, на критичные методы вроде оплаты и создания заказа и на «тяжёлые» выборки. Критичные пользовательские сценарии защищайте сильнее фоновых выгрузок и аналитических обходов.

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

Обязательно заложите исключения и ручное повышение квоты по заявке с фиксацией срока. Иначе каждый крупный партнёр будет обходить политику «серыми» ключами, и вы вернётесь к той же дыре под другим именем.

Сопровождайте политику документацией и контрактом: сколько запросов, в каком окне, что считается злоупотреблением, как запросить увеличение, что происходит при превышении. Это часть продукта API, а не примечание мелким шрифтом для «продвинутых».

Если сейчас шлюз уже живёт в проде без квот, имеет смысл системная настройка API: аудит потребителей, политика лимитов, мониторинг и аккуратный-rollout, чтобы один клиент больше не устраивал отказ для всех.

Что ещё закрыть вместе с лимитами

Ротация и отзыв ключей. Забытый ключ без срока жизни и без владельца — бомба замедленного действия, которая тикает независимо от вашей уверенности в текущих партнёрах.

Идемпотентность и пагинация для тяжёлых методов. Лимит без нормального дизайна API лишь маскирует плохие паттерны потребления: клиенты всё равно будут пытаться выгрузить «всё сразу», просто чаще упираясь в потолок.

Отдельные контуры для публичного и привилегированного доступа. Админские и внутренние вызовы не должны делить судьбу с партнёрским штормом и наоборот.

Алерты: всплеск по ключу, доля отказов по лимиту, рост задержки на критичных методах, аномальный рост одного потребителя относительно его базы. Лимит без наблюдаемости снова превращается в «узнали от клиентов».

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

Не забудьте про партнёрский кабинет самообслуживания: кабинет или заявку, где можно увидеть остаток квоты и запросить повышение. Иначе лимиты будут обходить через новых ключей и теневые интеграции.

Итог для бизнеса

Rate limits — это страховка выручки и репутации. Сайт и API остаются доступны честным пользователям, партнёры получают предсказуемые правила, инциденты «один скрипт убил прод» уходят из практики. Вы перестаёте платить железом и нервами за чужие циклы и собственные забытые ключи.

Управление потреблением становится частью продукта: прозрачные тарифы, понятные отказы, контролируемый рост интеграций. Это снижает стоимость сопровождения и повышает доверие крупных партнёров, которым важна стабильность не меньше, чем ширина API.

Если сегодня один client может положить backend — это не вопрос «успеем ли до пика сезона». Это вопрос, успеете ли вы внедрить политику до следующего бесконечного цикла в чужом коде. Пока квот нет, любой успешный интегратор потенциально опаснее внешнего бота: он уже внутри с валидным ключом.