Límites de tasa explicados para desarrolladores de bots

Por qué existen los límites

Las plataformas comparten infraestructura entre millones de bots y usuarios. Los límites protegen esa infraestructura y protegen a los usuarios del spam. Para quien desarrolla bots, además, definen la velocidad máxima de todo lo que construyas: una difusión a 10,000 usuarios a 30 mensajes por segundo tarda más de cinco minutos sin importar qué tan rápido sea tu servidor.

Cómo se miden los límites

La mayoría de las APIs usa uno de tres algoritmos. Puedes verlos lado a lado en el playground de límites de tasa.

• Ventana fija: N peticiones por ventana (por ejemplo, por minuto). Es sencilla, pero permite hasta el doble del límite alrededor del cambio de ventana.
• Ventana deslizante: cuenta las peticiones de los últimos N segundos en cualquier momento. Es más uniforme y más estricta.
• Token bucket: una cubeta se recarga a ritmo constante; cada petición toma un token; se permiten ráfagas cortas hasta el tamaño de la cubeta.

Los límites también tienen un alcance: por chat, por canal, por ruta, por bot o por app. Un bot puede estar muy por debajo de su límite global y aun así recibir throttling en un solo chat con mucha actividad.

Los límites que más importan

Las cifras exactas, sus fuentes y la fecha de última revisión están en nuestra tabla de límites de tasa. El comparador estima cuánto tarda enviar N mensajes en cada plataforma.

Cómo leer un 429

El código HTTP 429 Too Many Requests significa "baja la velocidad". La respuesta suele decirte por cuánto tiempo:

• El encabezado estándar Retry-After, en segundos.
• Telegram devuelve parameters.retry_after en el cuerpo JSON.
• Discord devuelve retry_after en el cuerpo y encabezados X-RateLimit-* que describen el bucket, como X-RateLimit-Remaining y X-RateLimit-Reset-After, para que puedas frenar antes de llegar al límite.

Espera siempre al menos el tiempo que pide el servidor. Reintentar de inmediato alarga la penalización, y las peticiones no válidas repetidas pueden provocar un bloqueo temporal del bot: Discord documenta un límite de peticiones no válidas (respuestas 401, 403 y 429) por dirección IP.

Backoff con jitter

Para errores sin una espera indicada por el servidor (timeouts, 502, 503), reintenta con backoff exponencial y jitter: espera un tiempo aleatorio entre cero y un tope que se duplica tras cada fallo. El jitter evita que todos tus workers reintenten en el mismo instante. Limita el número de intentos y reintenta solo operaciones idempotentes, o usa una clave de idempotencia. La calculadora de backoff genera el calendario de reintentos y el código.

Aplica throttling antes de llegar al límite

El mejor 429 es el que nunca recibes:

1. Pon los envíos en una cola en lugar de llamar a la API desde cada handler.
2. Limita por alcance: un token bucket por chat y uno global.
3. Reparte las difusiones en el tiempo y envíalas por debajo del límite documentado, dejando margen para las respuestas interactivas.
4. Prioriza: primero las respuestas a usuarios, después los mensajes masivos.
5. Mide los 429 como métrica. Un aumento es una alerta temprana.

Errores comunes

• Tratar como globales límites que son por chat (o al revés).
• Correr varias instancias que creen tener todo el límite para ellas. Usa un limitador compartido (Redis, un Durable Object) o un solo proceso emisor.
• Reintentar errores 4xx distintos de 429: una petición incorrecta volverá a fallar.
• Escribir límites fijos en el código sin fuente. Las plataformas los cambian; guarda el número en la configuración.

Fuentes

• FAQ de bots de Telegram: core.telegram.org/bots/faq
• Límites de tasa de Discord: discord.com/developers/docs/topics/rate-limits
• Límites de tasa de Slack: api.slack.com/apis/rate-limits
• Rendimiento de WhatsApp Cloud API: developers.facebook.com/docs/whatsapp/cloud-api/overview
• RFC 6585, código de estado 429: rfc-editor.org/rfc/rfc6585