Convertir Rate Limit API: RPM, RPS y RPD 🇦🇷

Cómo se calcula

Las conversiones entre unidades de rate limit son divisiones y multiplicaciones exactas basadas en los segundos de cada período:

# Conversiones exactas
RPS  = valor_RPM  / 60
RPS  = valor_RPD  / 86400

RPM  = valor_RPS  * 60
RPM  = valor_RPD  / 1440

RPD  = valor_RPS  * 86400
RPD  = valor_RPM  * 1440

# Ejemplo: 60 RPM
RPS = 60 / 60        = 1.0000 RPS
RPD = 60 * 1440      = 86 400 RPD

# Ejemplo: 500 RPS
RPM = 500 * 60       = 30 000 RPM
RPD = 500 * 86400    = 43 200 000 RPD

> Nota de precisión: RPD = RPM × 1 440 (minutos/día = 24 × 60). RPD = RPS × 86 400 (segundos/día = 24 × 3 600).

---

Tabla de referencia

Valores típicos de rate limits de APIs populares en 2025:

> RPH = Requests Per Hour (÷ 3 600 para convertir a RPS).

---

Casos típicos

Caso 1 — Chatbot con GPT-4o en plan gratuito

RPS = 3 / 60 = 0.05 RPS

Esto significa que solo puede hacer 1 consulta cada 20 segundos. Si el bot recibe 5 mensajes simultáneos, 4 quedarán en cola o recibirán error 429. La solución es implementar un queue con delay mínimo de 20 s entre llamadas, o upgradearse al Tier 1 (500 RPM = 8,33 RPS).

Caso 2 — E-commerce con MercadoPago

RPS_disponible = 600 / 60 = 10 RPS
Demanda_pico   = 800 / 3600 = 0.22 RPS
Margen          = 10 / 0.22 = 45x  ✓ sobra margen

Incluso en el pico más exigente, el límite no se alcanza. Sin embargo, si un worker mal configurado hace polling cada 100 ms (10 RPS solo), consume toda la cuota.

Caso 3 — Configurar NGINX como API Gateway

RPS = 1200 / 60 = 20 RPS

# nginx.conf
limit_req_zone $binary_remote_addr zone=api:10m rate=20r/s;
limit_req zone=api burst=40 nodelay;

El parámetro burst=40 permite absorber picos de hasta el doble del rate durante 2 segundos sin devolver 503.

---

Errores comunes

1. Confundir RPM de API con RPM de motor: El contexto importa. En tecnología, RPM siempre es Requests Per Minute, no revoluciones. Si copiás un valor de documentación de hardware, verificá las unidades.

2. Ignorar el límite por token/usuario vs. límite global: Muchas APIs (OpenAI, GitHub) tienen rate limits por API key Y por IP. Escalar horizontalmente con múltiples workers bajo la misma key NO multiplica el límite.

3. No contemplar retries en el cálculo: Si tu sistema hace retry automático ante error 429 con 3 intentos, el consumo real de RPS puede triplicarse en escenarios de saturación, generando un loop de saturación.

4. Asumir que el límite es parejo en el tiempo: Algunos proveedores usan ventanas deslizantes (sliding window) y otros usan ventanas fijas (fixed window). En ventana fija, podés gastar 60 RPM en los primeros 5 segundos y quedar bloqueado los 55 restantes.

5. Olvidar convertir RPH a RPS/RPM: La API de GitHub usa Requests Per Hour (5 000 RPH). Dividir por 60 da RPM (83,3), no RPS. El error de conversión puede hacer que configures un cliente 60 veces más restrictivo de lo necesario.

6. No sumar los endpoints: Si tu app llama a /users y a /orders de la misma API, ambos endpoints comparten la cuota global. No importa que cada endpoint parezca "lento"; la suma de todos los calls cuenta contra el mismo límite.

---