Throttling vs. rate limiting: cómo evitar que tus automatizaciones colapsen por errores 429

Por qué una automatización saludable se detiene de golpe

Una ráfaga de errores 429 (Too Many Requests) puede paralizar un flujo de trabajo que hasta hace minutos funcionaba perfectamente. Cuando una pyme conecta su CRM, su facturación o su sistema de soporte con otras herramientas mediante APIs, ese tipo de error aparece antes o después. La reacción instintiva suele ser reintentar el envío cuanto antes, pero ahí está buena parte del problema: reintentar demasiado rápido suele chocar con el mismo límite.

La noticia original de n8n aborda justamente esta cuestión: la diferencia entre throttling y rate limiting, y cómo diseñar estrategias de reintento que no empeoren la situación. Es un tema técnico, pero con consecuencias muy concretas para cualquier negocio que dependa de la automatización para operar.

Quién impone el límite y quién debe adaptarse

Ambos mecanismos controlan cuánto tráfico llega a una API, pero no tratan igual los excesos. El rate limiting establece un tope de peticiones por periodo: si lo superás, el proveedor rechaza las siguientes, normalmente con un 429. El throttling, en cambio, puede ralentizar o encolar las peticiones cuando el volumen supera el ritmo permitido, en lugar de rechazarlas de plano.

La clave está en que el proveedor siempre controla la política. Tu organización, como consumidora de la API, solo controla cómo responde su flujo: puede espaciar solicitudes para no llegar al límite y retroceder cuando lo alcanza. Esa asimetría cambia por completo el enfoque de diseño de cualquier automatización.

Qué significa cada comportamiento para tu flujo

Imagina que una API admite cien peticiones por minuto y tu automatización envía la número ciento uno antes de que termine el minuto. Con rate limiting, esa petición probablemente será rechazada y tu flujo tendrá que decidir cuándo reintentar. Con throttling, el proveedor puede retenerla en una cola y procesarla más tarde.

El resultado visible es distinto (un error frente a una demora), pero el control sigue estando del lado del proveedor. Para una pyme, la diferencia práctica es que un error exige lógica de reintento, mientras que una demora exige tolerancia en los pasos posteriores que dependen de esa respuesta.

No todos los límites se miden igual

Los proveedores no aplican el mismo algoritmo, y eso afecta cómo conviene dosificar las llamadas. Algunos usan ventanas fijas: permiten cierto número de peticiones y reinician el contador al empezar el siguiente intervalo. Otros emplean ventanas deslizantes, que miden continuamente lo solicitado en el último periodo, de modo que esperar a que cambie el reloj no restablece automáticamente la cuota.

También existen los modelos de token bucket, que permiten ráfagas si se han acumulado tokens disponibles, y los de leaky bucket, que suavizan las ráfagas encolando las peticiones para que salgan a ritmo constante. La recomendación es clara: revisar la documentación de límites del proveedor antes de decidir con qué agresividad conviene agrupar o espaciar las llamadas.

Qué hacer cuando aparece el 429

El código 429 indica que se superó el límite. La respuesta puede incluir una cabecera Retry-After que señala cuánto esperar antes de reintentar. Si está presente, conviene respetarla en lugar de adivinar. Si no aparece, el flujo necesita su propia estrategia de espaciado.

Ahí entra en juego el backoff exponencial: en vez de reintentar de inmediato o siempre al mismo intervalo, se aumenta progresivamente la espera tras cada intento fallido. Un flujo puede esperar uno, dos, cuatro, ocho segundos, y así sucesivamente. Es fundamental fijar un retardo máximo y un número límite de reintentos para no dejar el proceso en un bucle indefinido.

El detalle que muchos pasan por alto: el jitter

Hay una trampa adicional. Varios flujos que fallan al mismo tiempo también reintentan al mismo tiempo, generando otra ola de tráfico contra la API. Añadir jitter, una pequeña dosis de aleatoriedad en cada espera, dispersa esos intentos y reduce la probabilidad de provocar un nuevo pico.

Además, antes de reintentar automáticamente hay que confirmar que la petición es segura de repetir. Las operaciones con efectos secundarios, como crear un registro o emitir una factura, pueden ejecutarse dos veces si no se comprueba si la API admite idempotencia.

Lectura práctica para una pyme

La mayoría de las pymes no construye sus integraciones desde cero, sino que se apoya en plataformas de automatización como n8n, que ya ofrecen mecanismos para espaciar solicitudes y gestionar reintentos. Aun así, entender qué hay detrás de esos límites ayuda a tomar mejores decisiones: elegir bien los intervalos, no saturar los servicios externos y diseñar flujos que toleren demoras.

Si tu empresa depende de automatizaciones para facturar, sincronizar contactos o atender pedidos, un fallo por límite de API puede traducirse en horas de trabajo manual. Revisar cómo están configurados los reintentos y el ritmo de las llamadas es una inversión pequeña con impacto directo en la continuidad operativa. En Altya Studio podemos ayudarte a auditar esos flujos y a diseñarlos para que resistan los límites de las APIs sin intervención constante.

Fuente: blog.n8n.io