# Requests Per Minute (RPM)

> **Requests Per Minute (RPM)** или «запросы в минуту» — это базовая метрика в IT и веб-разработке, показывающая суммарное количество обращений, которые сервер, приложение или API получает и обрабатывает за одну минуту.

## Что такое RPM и почему это важно?

В мире веб-разработки, системного администрирования и создания облачных сервисов понимание нагрузки на систему является критически важным фактором. Метрика RPM помогает разработчикам и владельцам бизнеса оценить, насколько активно пользователи или сторонние программы взаимодействуют с их цифровым продуктом. Эта единица измерения является золотой серединой для оценки трафика: она более показательна для бизнес-логики, чем запросы в секунду (RPS), и более детализирована, чем запросы в час.

Мониторинг этого показателя позволяет решать сразу несколько стратегических задач:

- **Предотвращение сбоев (Downtime):** Если показатель RPM резко возрастает в десятки раз, сервер может исчерпать свои ресурсы (процессорное время, оперативную память) и «упасть». Постоянный контроль позволяет вовремя заметить аномалию.
- **Масштабирование инфраструктуры:** Понимая средний и пиковый RPM, DevOps-инженеры могут настраивать автоскейлинг — автоматическое добавление новых серверов в часы пик и их отключение ночью для экономии бюджета.
- **Тарификация и ограничение доступа (Rate Limiting):** Практически все современные SaaS-платформы и коммерческие API продают доступ к своим данным, базируясь на лимитах запросов в минуту.
- **Выявление кибератак:** Аномальный всплеск RPM с одного IP-адреса часто свидетельствует о попытке агрессивного парсинга данных, брутфорсе (подборе паролей) или начинающейся DDoS-атаке.

## Чем RPM отличается от RPS?

Часто новички путают RPM с другой популярной метрикой — RPS (Requests Per Second, запросы в секунду). Хотя суть у них одинаковая, применяются они в разных контекстах. RPS используется для оценки производительности высоконагруженных систем (Highload), где счет идет на тысячи операций в одно мгновение. RPM же чаще применяется для оценки работы API, фоновых задач (cron jobs), лимитов для пользователей или аналитики посещаемости сайтов со средним трафиком.

## Примеры использования RPM в реальной жизни

С метрикой Requests Per Minute мы сталкиваемся гораздо чаще, чем может показаться на первый взгляд. Вот несколько наглядных примеров того, как она работает на практике:

### 1. Использование нейросетей и API

Если вы когда-либо интегрировали в свои проекты современные нейросети (например, от OpenAI, Google или Anthropic), вы наверняка видели ограничения в документации. Бесплатный тариф (Free Tier) может ограничивать вас до 3 RPM. Это значит, что вы можете отправить только 3 промпта в минуту. Для корпоративных клиентов этот лимит может составлять 10 000 RPM и более, что позволяет обслуживать тысячи пользователей одновременно.

### 2. Работа интернет-магазина в период распродаж

Представьте классический интернет-магазин. В обычный будний день он обрабатывает около 100-200 RPM — пользователи неспешно листают каталог, добавляют товары в корзину, оформляют заказы. Но в день старта «Черной пятницы» запускается масштабная email-рассылка. Нагрузка мгновенно возрастает до 5 000 RPM. Если база данных и веб-серверы не рассчитаны на такой скачок, сайт просто перестанет открываться, выдавая ошибку 502 Bad Gateway.

### 3. Интеграция с платежными шлюзами

Банковские API также строго контролируют RPM. Если ваш сервис попытается проводить тысячи транзакций в минуту без предварительного технического согласования, автоматика банка заблокирует ваш шлюз, расценив это как мошенническую активность (фрод) или критический сбой в коде вашего приложения.

## Интересный факт: Как появился код ошибки 429

Когда вы превышаете допустимый лимит RPM, сервер обычно прерывает обработку и возвращает вам HTTP-статус **429 Too Many Requests** («Слишком много запросов»). Но мало кто знает, что этот статус не входил в изначальную спецификацию HTTP, созданную Тимом Бернерсом-Ли в начале 90-х годов.

В первые годы существования интернета разработчики использовали статус *503 Service Unavailable* или даже *400 Bad Request*, чтобы отбиваться от назойливых ботов и слишком частых обращений. Это создавало огромную путаницу: код 503 означает проблему на стороне сервера, хотя виноват был клиент, отправляющий слишком много запросов. Лишь в 2012 году, когда API стали основой современного интернета, а необходимость жестко контролировать RPM стала критической для бизнеса, был официально принят стандарт RFC 6585. Он ввел статус 429, который теперь является универсальным языком общения между серверами. Он буквально означает: «Остановись, ты превысил свой лимит RPM, попробуй позже!»