Hard limits и алерты

Что это за тема

Два механизма защиты от перерасхода в кабинете провайдера API. Алерт предупреждает, hard limit останавливает. Вместе они закрывают и «незаметно набежало», и «цикл в коде накрутил счёт».

Зачем это понимать

Без лимитов один баг превращается в реальные деньги. Бесконечный цикл, ошибка в логике повторов, утёкший ключ - и за ночь расход уходит далеко за план. Hard limit делает максимальный ущерб предсказуемым.

Как это устроено

Алерт (soft limit). Задаёте пороги - например, уведомление на 25, 50 и 80% от ожидаемого месячного бюджета. При достижении провайдер шлёт письмо. Запросы продолжают идти. Задача алерта - заметить аномалию рано.

Hard limit. Задаёте потолок расхода за период. Достигли - провайдер перестаёт принимать запросы до следующего периода или до повышения лимита. Задача - ограничить максимальный ущерб.

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

Пример

Бюджет на проект - условные 100 единиц в месяц.

• алерт на 50 - «идём по плану, всё нормально»,
• алерт на 80 - «пора проверить, не аномалия ли»,
• hard limit на 130 - дальше запросы не принимаются.

Если из-за бага расход рванул вверх, вы получите письмо на 80, а на 130 всё остановится само. Числа - ориентир, подберите под свой проект.

Антипаттерны

• Ставить только алерт. Письмо легко пропустить ночью или в выходные.
• Один hard limit на всё. Без разбивки по ключам непонятно, какой проект съел бюджет.
• Лимит «на глаз», без прикидки. Поставьте его от оценки из раздела 02, а не наугад.

Что дальше

Дальше - как снижать сам расход: выбор модели, короткий контекст, кэш, батчинг и опенсорс.