Rate Limiting
Qué es
Rate Limiting es una política que restringe cuántas operaciones pueden atravesar una frontera durante un período o presupuesto determinado. Define qué se cuenta, para quién, dónde y qué ocurre al excederlo. Puede proteger uso compartido, contener costos o respetar el contrato de una dependencia, incluso cuando no existe saturación física.
Un límite puede medirse en requests, bytes o unidades de costo. «100 requests por segundo» presupone una unidad concreta; no demuestra capacidad para cien consultas arbitrarias. Una cuota mensual limita consumo acumulado y no reemplaza un límite que controle bursts de segundos.
La política puede aplicarse al recibir tráfico o al emitirlo. Azure Architecture Center describe regulación del envío para mantenerse dentro de límites de un servicio, evitando trabajo adicional de rechazos y reintentos. Rate Limiting pattern.
Ventanas y presupuestos
| Modelo | Idea conceptual | Trade-off relevante |
|---|---|---|
| Fixed window | Cuenta operaciones dentro de intervalos delimitados. | Puede concentrar tráfico a ambos lados de una frontera temporal. |
| Sliding window | Evalúa consumo sobre un horizonte móvil. | Mayor precisión o suavidad puede exigir más estado; existen aproximaciones. |
| Token bucket | Repone un presupuesto a una tasa y permite acumularlo hasta un límite. | La capacidad del bucket determina el burst permitido. |
| Leaky bucket como shaper | Espacia salida a un ritmo previsto usando espera acotada. | Suavizar emisión agrega latencia y exige resolver desborde. |
Son familias, no algoritmos intercambiables con idénticas garantías. La documentación de Microsoft ilustra fixed y sliding windows y los separa de un límite de concurrencia, que no usa un período temporal. Rate limiting middleware.
RFC 3290 describe token buckets y leaky buckets en el contexto de control de tráfico, distinguiendo medición de conformidad y shaping. Esa terminología no siempre se usa igual en bibliotecas de aplicaciones; debe comprobarse la semántica concreta. Discussion of Token Buckets and Leaky Buckets.
Burst capacity
Un bucket con reposición de 100 tokens por segundo y capacidad de 200 puede permitir una ráfaga inmediata de 200 operaciones cuando está lleno. No significa «nunca más de cien dentro de cualquier segundo». Bajo el modelo ideal, presupuesto acumulado y reposición determinan lo permitido; granularidad y coordinación pueden añadir aproximaciones.
Un límite por ventana fija de cien también puede permitir cien operaciones justo antes del cambio de ventana y otras cien justo después. Eso respeta ambos contadores y aún produce un pico local. El contrato debe expresar qué burst tolera el receptor, en lugar de prometer suavidad a partir de un promedio.
AWS API Gateway documenta rate y burst mediante token bucket, pero aclara que sus límites son objetivos de throttling de mejor esfuerzo, no techos garantizados en toda circunstancia. Este ejemplo muestra por qué hay que distinguir política deseada de garantía implementada. Request throttling.
Scope e identidad
Scopes habituales son usuario, tenant, API key, endpoint, cliente y total global. Pueden combinarse: una solicitud necesita cuota del tenant y del endpoint compartido. Un scope describe quién comparte presupuesto; la clave debe corresponder a una identidad estable y suficientemente confiable para ese propósito.
Límites por IP pueden agrupar muchos usuarios detrás de una red y permitir evasión mediante múltiples direcciones. Una API key representa al titular o aplicación según el contrato, no necesariamente a una persona. Crear más claves no debería multiplicar automáticamente una cuota de tenant si se pretende proteger ese consumo agregado.
Un límite local por instancia se multiplica con el número de instancias. Coordinar estado global puede aumentar costo y dependencia operativa; aproximar presupuestos repartidos tolera excedentes que deben reconocerse. No hace falta elegir una implementación distribuida si la frontera protegida es deliberadamente local.
Al exceder el presupuesto
Las opciones incluyen rechazo explícito o espera bounded para shaping. Encolar sin límite transforma protección temporal en backlog ilimitado. queue-management debe aclarar edad, espacio y salida de lo que espera. Si ya se aceptó una obligación durable, superar cuota más tarde no autoriza borrarla.
HTTP 429 comunica exceso de solicitudes durante un período y puede incluir Retry-After. RFC 6585 no fija cómo identificar al usuario ni cómo contar solicitudes. 429 Too Many Requests. El código informa la condición; no garantiza que el cliente reduzca tráfico ni vuelve seguro repetir efectos.
retry inmediato puede agregar presión a un límite ya agotado. Respetar la espera indicada, presupuestos y vigencia es parte de una política válida; backoff y jitter ayudan a espaciar tentativas. También debe definirse si intentos fallidos o rechazados consumen presupuesto, evitando reglas ambiguas que favorezcan evasión o penalicen indebidamente recuperación.
Diferencias obligatorias
Rate Limiting no equivale a admission-control. Limitar cantidad en el tiempo puede ser una condición de admisión; decidir según capacidad actual es otra. Tener cuota no garantiza recursos ahora.
Rate Limiting no equivale a bulkhead. Cien req/s mide ritmo; veinte llamadas simultáneas a Payment mide ocupación. Si las llamadas duran más, la misma tasa puede agotar el límite concurrente.
Rate Limiting no equivale a backpressure. Una cuota puede mantenerse fija con el receptor vacío. Backpressure comunica presión y busca una reacción upstream; un limitador adaptativo puede participar en ese feedback, sin representar todo el mecanismo.
Ejemplo, trade-offs y uso
En API Gateway → Order → Payment, 100 req/s son normales y la capacidad aproximada es 120. Ante 300, un presupuesto de entrada ilustrativo de cien restringe la tasa según su burst. Un Bulkhead de veinte limita concurrencia hacia Payment; admisión puede rechazar porque esos permisos están agotados, y backpressure puede pedir desaceleración upstream.
Si Payment pierde capacidad y solo sostiene 60 req/s, el límite de cien ya no evita overload. Si operaciones baratas podrían aprovechar más capacidad, un límite excesivamente bajo desperdicia oportunidades. Ninguna cifra debe elegirse sin conocer mezcla, scopes y garantías.
Usarlo para contratos temporales y reparto explícito de consumo. No usarlo como único diagnóstico de capacidad ni como defensa integral contra abuso. Observar tráfico ofrecido, permitido, rechazado, burst y espera por scope, junto con recursos y resultados útiles, permite comprobar tanto el contrato de cuota como su efecto operativo.