Limitación de tasa y protección contra abuso de APIs: token bucket, leaky bucket, cuotas y backoff

La limitación de tasa es uno de esos controles que parecen sencillos en un diagrama y se vuelven matizados cuando llega el tráfico real: clientes móviles que reintentan con redes inestables, integraciones de socios que envían lotes, bots que rotan direcciones IP y trabajos en segundo plano que, sin querer, “pisotean” el mismo endpoint. En 2026, la mayoría de APIs en producción combinan varias técnicas: token bucket para tolerar ráfagas, leaky bucket para suavizar, cuotas para repartir el uso en ventanas largas y reglas de backoff para impedir que los reintentos conviertan un fallo parcial en una caída total. Este artículo explica cómo encajan estas piezas, qué riesgos cubren y qué decisiones de diseño suelen importar más que el nombre del algoritmo.

Qué protege realmente la limitación de tasa: disponibilidad, coste y equidad

En lo básico, la limitación de tasa evita que un solo consumidor—malicioso o simplemente defectuoso—acapare CPU, conexiones de base de datos o capacidad de servicios aguas abajo. No se trata solo de “demasiadas solicitudes”; se trata de proteger recursos compartidos y mantener la latencia predecible para el resto. Un único endpoint con fan-out caro (búsqueda, recomendaciones, llamadas a terceros) puede convertirse en el punto débil que empuja a todo el sistema a colas crecientes.

También protege el coste y los límites contractuales. Muchas APIs públicas tienen detrás un modelo económico: ancho de banda, cómputo, niveles de pago o acuerdos con partners. Incluso las APIs internas pueden estar condicionadas por costes cuando se apoyan en servicios medidos. La limitación de tasa vuelve aplicables esos límites y, cuando se acompaña de cuotas claras, permite comunicar expectativas sin depender de bloqueos silenciosos o promesas vagas de “mejor esfuerzo”.

Por último, es un mecanismo de equidad. Dos clientes pueden ser “legítimos” y aun así perjudicarse: uno envía tráfico constante y otro dispara picos al inicio de cada minuto. Sin un limitador que entienda ráfagas y suavizado, el cliente con picos puede dominar la concurrencia y empujar al estable a timeouts. Un buen esquema reduce la necesidad de autoscaling agresivo que solo tapa el problema.

Elegir límites que reflejen cuellos de botella reales

La primera decisión es qué unidad estás limitando. “Solicitudes por segundo” es fácil de medir, pero puede engañar cuando las solicitudes tienen costes muy distintos. En la práctica, muchos equipos introducen límites ponderados: una lectura barata vale 1 unidad, una búsqueda compleja vale 5 y una exportación por lotes vale 20. Así, la limitación se alinea con el cuello de botella real—CPU, IO de base de datos o cuotas de un tercero—y no con un simple conteo de requests.

Luego viene el alcance: por IP, por clave de API, por cuenta de usuario, por organización o por credencial más endpoint. Los límites solo por IP son fáciles de evadir y pueden castigar redes corporativas con NAT. Los límites solo por clave fallan cuando una clave se filtra. En APIs públicas, lo más robusto suele ser un enfoque por capas: salvaguardas moderadas por IP para frenar exploración evidente, controles fuertes por clave o cuenta para equidad y, si hace falta, límites por ruta para endpoints particularmente caros.

La elección de la ventana temporal también es una elección de fiabilidad. Ventanas cortas (por segundo) ayudan contra ráfagas, mientras que ventanas largas (por minuto/hora/día) controlan el consumo sostenido. A propósito, muchos diseños usan al menos dos ventanas: un limitador de corto plazo que protege la capacidad instantánea y una cuota de largo plazo que hace cumplir el contrato de uso.

Token bucket vs leaky bucket: ráfagas, suavizado y detalles de implementación

Token bucket y leaky bucket suelen presentarse como alternativas, pero en sistemas reales resuelven problemas distintos. Token bucket está pensado para permitir ráfagas: los tokens se acumulan hasta una capacidad máxima y cada solicitud consume tokens. Si el cliente estuvo inactivo, puede “ahorrar” capacidad y enviar una ráfaga corta sin ser bloqueado. Esto encaja bien con comportamientos reales—apps que despiertan, colas que se vacían, partners que envían lotes—y evita penalizar patrones naturales.

Leaky bucket, en cambio, está orientado al suavizado. Puedes imaginarlo como una cola que se drena a un ritmo constante. Si las solicitudes llegan más rápido que ese ritmo, la cola se llena y el exceso se retrasa o se rechaza. Este modelo es útil cuando el recurso protegido se degrada con carga a ráfagas: una base de datos que “se cae por el borde” cuando sube el churn de conexiones, o un servicio aguas abajo con capacidad estricta por segundo.

En la práctica, a menudo se aplica token bucket en el borde (gateway, proxy inverso, ingress) y un suavizado tipo leaky bucket cerca del cuello de botella (colas de trabajo, ejecutores por inquilino/tenant, poolers de base de datos). El limitador en el borde frena inundaciones súbitas, mientras que el suavizado interno protege las partes frágiles de la variación que aún logra pasar.

Errores comunes: límites distribuidos, deriva de reloj y falsos positivos

Un error clásico es intentar imponer un límite global único en muchos nodos sin pensar en la consistencia. Si cada nodo aplica “100 solicitudes/segundo” de forma independiente, el límite efectivo pasa a ser “100 por nodo”. Para evitarlo, necesitas estado compartido (por ejemplo, un almacén central) o una estrategia deliberada como límites locales más una cuota global verificada con menos frecuencia. En 2026 sigue siendo normal aceptar aproximaciones en el borde, porque la precisión global perfecta suele costar más en latencia y complejidad que lo que aporta en equidad.

Las suposiciones sobre tiempo también pueden fallar. Ventanas deslizantes, ventanas fijas y recargas de tokens se comportan distinto en los bordes. Las ventanas fijas (por ejemplo, reinicio cada minuto) crean efectos de frontera donde los clientes pican a las 12:00:00. Las ventanas deslizantes reducen eso, pero pueden ser más pesadas de calcular. Token bucket evita parte del problema, pero igualmente debes decidir granularidad de recarga y si los tokens se rellenan de forma continua o por “ticks”.

Los falsos positivos suelen venir de identidad y topología de red, no del algoritmo. NAT, pasarelas de operadores móviles y proxies corporativos hacen que muchos usuarios parezcan una sola IP. A la vez, redes de bots hacen que un solo actor parezca muchas IPs. Si te apoyas solo en IP, arriesgas bloquear usuarios reales y apenas frenar el abuso. Si te apoyas solo en claves, una fuga de clave puede causar daño sostenido. Los límites por capas y la detección de anomalías—uso repentino desde nuevas regiones, endpoints inusuales o tasas extremas de error—reducen ambos riesgos.

Cuotas y backoff: convertir el throttling en un contrato estable

Limitar sin feedback claro genera comportamiento caótico en el cliente: reintentos en bucle, demoras aleatorias o lógica de “prueba otra vez” dispersa por el código. Las cuotas formalizan qué significa “uso justo” en periodos más largos—por minuto, hora o día—y permiten niveles o asignaciones por partner. También ayudan durante incidentes: puedes reducir temporalmente asignaciones, priorizar clientes críticos y evitar que el sistema oscile mientras se recupera.

El backoff es lo que impide que los reintentos se conviertan en un amplificador. Cuando un servicio se degrada, sube la latencia y la tasa de errores. Los clientes que reintentan de inmediato añaden carga y empeoran la situación. El backoff exponencial con jitter es el enfoque estándar en 2026 porque reparte reintentos en el tiempo y evita tormentas sincronizadas. El “jitter” importa: si todos duplican retrasos al mismo ritmo, seguirán chocando.

Para que cuotas y backoff funcionen juntos, necesitas señales consistentes. Cuando frenas a un cliente, devuelve un estado apropiado (a menudo HTTP 429) y, si puedes, incluye orientación sobre cuánto esperar. Señales claras permiten que los SDKs implementen reintentos seguros de forma centralizada, en vez de obligar a cada integrador a adivinar.

Diseño práctico de respuestas: 429, cabeceras y comportamiento del cliente

Una buena respuesta de throttling es explícita y fácil de procesar por máquinas. En APIs HTTP, 429 se usa ampliamente para indicar que el cliente superó un límite, y muchos clientes ya lo interpretan. Incluir una cabecera Retry-After es útil cuando puedes calcular una espera sensata. Incluso si no puedes ser exacto, un valor conservador suele evitar martilleo inmediato y reduce tráfico desperdiciado.

También ayuda publicar los límites como parte del contrato para que los clientes se autorregulen. Muchas APIs exponen el límite y lo “restante” mediante cabeceras o documentación para desarrolladores. Aquí conviene ser preciso con la semántica: “restante” puede ser por minuto, por hora o por ventana móvil, y los clientes se comportarán mal si lo interpretan al azar. Si aplicas varios limitadores (ráfaga por segundo y cuota diaria), deja claro qué señal corresponde a cada restricción.

Del lado del cliente, el comportamiento seguro suele incluir: backoff exponencial con jitter, un tope máximo de espera, un máximo de reintentos e idempotencia para operaciones que puedan repetirse. Para escrituras, las claves de idempotencia suelen marcar la diferencia entre “un reintento es inocuo” y “un reintento duplica un pago”. Trata el backoff como parte de la corrección, no solo del rendimiento: protege tu servicio y también protege a los usuarios de acciones duplicadas y fallos parciales confusos.