Un rate limit define cómo se comparte la capacidad: quién la usa, cómo se tratan los picos, qué ocurre al llegar al límite y cómo se recupera el cliente. Un “100 solicitudes por minuto” genérico puede proteger el servicio y a la vez castigar lotes normales, ignorar endpoints caros o hacer que los reintentos amplifiquen una caída.
Empieza por el objetivo: proteger la base de datos, aislar clientes, controlar una llamada costosa de IA, frenar abuso de credenciales o cumplir una cuota contractual. Son políticas distintas. La cuota de producto debe poder explicarse; el límite protector puede ser temporal y adaptativo.
| Contador | Protege | Riesgo si se usa solo |
|---|---|---|
| Solicitudes por clave/cuenta | Acceso equitativo y contención de abuso. | Lectura barata y escritura cara cuestan igual. |
| Unidades ponderadas por cliente | Coste de base, cómputo o IA. | Pesos desalineados del consumo real. |
| Concurrencia | Workers, conexiones y tareas largas. | No limita el consumo diario. |
| Presupuesto global | Infraestructura ante picos. | Un cliente ruidoso desplaza a los demás. |
| Cuota comercial | Plan o consumo facturado. | Debe cuadrar con cobro e intervalos de reset. |
Las APIs maduras combinan capas: equidad por credencial/cliente, coste por endpoint, límite de concurrencia y techo global de emergencia. Autentica antes del límite individual. El límite por IP ayuda ante abuso anónimo, pero puede penalizar a usuarios tras un NAT compartido.
Ventana fija es sencilla, pero permite picos en los bordes del reset. El log deslizante es preciso y conserva más datos; el contador aproximado reduce estado. Token bucket admite un pico definido y limita la tasa sostenida. Leaky bucket suaviza la salida. El límite de concurrencia restringe trabajo simultáneo y complementa la tasa. Decide por el comportamiento esperado, coste y consistencia.
HTTP 429 indica demasiadas solicitudes. RFC 6585 recomienda explicar la condición y permite Retry-After. Devuelve un código de error estable y el momento de reintento cuando sirva. No reveles el consumo de otro cliente ni capacidad interna. La respuesta 429 no debe almacenarse en caché como una respuesta normal.
Los SDK deben respetar Retry-After, usar backoff exponencial con jitter, acotar intentos y evitar repetir mutaciones no idempotentes sin clave. Los reintentos sincronizados crean una estampida al recuperarse el servicio. Para lotes, ofrece tamaño máximo o trabajos asíncronos en lugar de miles de llamadas pequeñas.
Un contador en proceso local es rápido, pero se reinicia y diverge entre réplicas. Uno central comparte visión con más latencia y dependencia. Control en el edge escala por región, pero requiere asignar presupuesto y tolerar exceso acotado. Decide entre cuota global estricta y disponibilidad si falla el contador; documenta fail-open/fail-closed por endpoint y riesgo.
El consumo facturable debe proceder de eventos duraderos o un ledger, no solo del contador temporal de throttling. El rate limit protege el servicio; no es automáticamente un medidor de cobro fiable.
Documenta cuotas por plan, picos, costes por endpoint, concurrencia, resets, paginación y retries. Muestra uso a responsables de cuenta y avisa antes del bloqueo cuando sea viable. Versiona cambios y ofrece transición. Soporte debe distinguir límite de una caída, fallo de autenticación o saldo agotado.
Observa 429 por cliente/ruta, coste aceptado, saturación, amplificación de retries, latencia y finalización de negocio. Rechazos repetidos con promedio bajo pueden indicar picos, supuestos de reloj o contador compartido injusto. Prueba vecinos ruidosos, ráfagas sincronizadas y caída del almacén del limitador.
Los rate limits definen cómo se integra el cliente. Aclara primero riesgo y capacidad, elige contadores/algoritmos apropiados, aplica ámbitos por capas, explica el 429 y define qué sucede si falla el estado del limitador. Un buen límite conserva acceso justo y una ruta previsible hacia el éxito.