¿Qué es el rate limiting? Guía en lenguaje sencillo para creadores de apps

El rate limiting es una regla que limita cuántas peticiones puede hacer alguien a un sistema en un periodo de tiempo determinado; por ejemplo, 5 intentos de inicio de sesión por minuto o 100 llamadas a la API por hora. Una vez alcanzado el límite, las peticiones siguientes se rechazan (normalmente con el código de error 429 Too Many Requests) hasta que se reinicia la ventana de tiempo. Protege las apps frente al abuso, evita que un usuario muy intensivo ralentice todo para los demás y frena los costes descontrolados.

El rate limiting te afecta desde dos lados: los servicios que tú llamas te limitan a ti, y tu propia app debería limitar a sus usuarios.

Por qué importa el rate limiting cuando construyes con IA

Las apps creadas con IA suelen conectarse a servicios de pago (modelos de IA, correo, SMS, mapas), y cada llamada cuesta dinero. Por eso el rate limiting es a la vez una función de seguridad y de presupuesto.

Control de costes. Si tu app tiene un cuadro de «pregúntale a la IA» y no tiene límite, un bot puede enviarle miles de peticiones durante la noche. Pagas por cada una.
Seguridad. Sin un límite en el formulario de inicio de sesión, un atacante puede probar miles de contraseñas contra una cuenta. Un límite de unos pocos intentos por minuto lo hace impracticable.
Mantenerse en línea. Un script que se comporta mal, a veces tu propio código atascado en un bucle, puede sobrecargar tu base de datos y tumbar la app.
Respetar los límites de otros servicios. Cuando tu app llama a una API externa con demasiada frecuencia, tú recibes los errores 429 y las funciones fallan para tus usuarios.

Los constructores de apps con IA crean lo que les pidas. Si no mencionas los límites, a menudo se quedan fuera.

Una analogía cotidiana

Piensa en la política de recargas gratis de una cafetería: «Una recarga gratis por cliente y visita».

No impide que nadie disfrute del café.
Impide que una persona se pase el día en la barra rellenando un termo para toda la oficina.
Cuando alguien pide una cuarta recarga, el camarero le dice amablemente «ahora no»: ese es el 429.

Un buen límite de frecuencia es invisible para los clientes normales y solo se nota en alguien que hace algo fuera de lo habitual.

Cómo funciona el rate limiting

Un limitador de frecuencia necesita tres elementos:

Parte	Pregunta que responde	Ejemplos
Quién	¿De quién se cuentan las peticiones?	Por cuenta de usuario, por dirección IP, por clave de API
Cuántas	¿Cuál es el límite?	5, 60, 1.000 peticiones
En qué tiempo	¿En qué ventana?	Por segundo, minuto, hora o día

Cuando llega una petición, la app comprueba el contador de ese «quién». Si está por debajo del límite, la petición pasa y el contador sube. Si lo supera, la petición se rechaza.

Hay algunas formas habituales de contar:

Método	Cómo funciona	Compromiso
Ventana fija	El contador se reinicia según el reloj; por ejemplo, cada minuto en punto	Sencillo, pero permite una ráfaga en el borde entre dos ventanas
Ventana deslizante	Mira los últimos 60 segundos desde ahora	Más suave, algo más de cálculo
Cubo de tokens (token bucket)	Cada usuario tiene un cubo que se rellena a un ritmo constante; cada petición consume un token	Permite ráfagas cortas manteniendo estable la media

Los contadores deben guardarse en un sitio rápido y compartido. En un servidor pequeño, la memoria basta. Cuando una app se ejecuta en varias máquinas, el contador suele vivir en un almacén compartido como Redis o la base de datos; si no, cada máquina cuenta por separado y el límite real puede ser varias veces mayor.

Cómo es una respuesta con límite alcanzado

Cuando una petición supera el límite, una API bien diseñada responde con:

Código de estado 429 Too Many Requests.
Normalmente, una cabecera Retry-After que indica cuántos segundos hay que esperar.
A veces, cabeceras que muestran tu límite y cuántas peticiones te quedan en esta ventana (los nombres varían según el proveedor).

Tu app debería responder a un 429 esperando y reintentando más tarde, idealmente con backoff exponencial: esperar un poco más tras cada intento fallido (1 segundo, luego 2, luego 4) en lugar de martillear el servicio.

Un ejemplo práctico: un asistente de escritura con IA

Supón que has creado una app en la que los usuarios pegan un texto y reciben una reescritura hecha por IA.

Sin límites: alguien escribe un script que envía 20.000 peticiones durante la noche. La factura de tu proveedor de IA se dispara, y tu cuenta alcanza el límite de frecuencia del propio proveedor, así que los usuarios reales ven errores toda la mañana.

Con límites razonables:

Por usuario conectado: 30 reescrituras por hora en el plan gratuito, 300 en los de pago. Al superar el límite, el usuario ve: «Has alcanzado el límite de esta hora. Inténtalo de nuevo en 12 minutos o mejora tu plan».
Por dirección IP en el formulario de registro: 5 registros por hora, para evitar que los bots creen miles de cuentas gratuitas y eludan el límite por usuario.
Un límite de gasto configurado en el panel de tu proveedor de IA, como última línea de defensa si todo lo demás falla.
Gestionar los límites del proveedor: si el proveedor de IA devuelve un 429, tu servidor espera y reintenta una o dos veces, y luego muestra un mensaje amable de «ocupado, inténtalo de nuevo».

Los límites se comprueban en el servidor. Un límite que solo existe en el navegador (por ejemplo, desactivar el botón tras 30 clics) puede eludirse por cualquiera que llame directamente a tu API.

Términos clave

Término	Significado
Rate limit	El número máximo de peticiones permitidas en una ventana de tiempo.
Cuota	Una asignación mayor, a menudo diaria o mensual, a veces ligada a un plan de pago.
429	El código de estado HTTP de «demasiadas peticiones».
Retry-After	Cabecera de respuesta que indica cuánto esperar antes de volver a intentarlo.
Throttling	Ralentizar o rechazar peticiones que superan un límite. Se usa a menudo como sinónimo.
Backoff exponencial	Esperar cada vez más tiempo entre reintentos.
Ráfaga (burst)	Un pico corto de muchas peticiones a la vez.
Ataque de fuerza bruta	Probar enormes cantidades de contraseñas o códigos hasta que uno funciona.

Malentendidos habituales

«El rate limiting solo es para apps grandes». Las apps pequeñas también son objetivos, porque los bots escanean internet en busca de formularios abiertos y endpoints de IA. El coste del abuso no depende de tu tamaño.
«Ocultar el botón basta». Los límites en el navegador son una cortesía, no una protección. Los límites reales deben aplicarse en el servidor.
«Los límites por IP siempre son justos». Muchas personas pueden compartir una misma dirección IP: una oficina, un colegio, una red móvil. Los límites por usuario son más justos una vez que las personas han iniciado sesión.
«Un 429 significa que el servicio está roto». Significa que lo estás llamando con demasiada frecuencia. Revisa tu código por si hay bucles y guarda en caché los resultados que no cambian a menudo; consulta qué es la caché.
«El rate limiting sustituye al límite de gasto». Usa ambos. Los límites de tu app pueden tener errores; el límite de gasto del proveedor es tu respaldo.

Qué pedir a tu constructor de IA

«Añade rate limiting en el servidor al inicio de sesión, al registro, a la recuperación de contraseña y al endpoint de IA. Sugiere límites razonables.»
«Limita a cada usuario conectado a [N] peticiones de IA por hora y muestra un mensaje claro con el tiempo de espera cuando lo alcance.»
«Cuando una API externa devuelva 429, reintenta con backoff exponencial hasta 3 veces y luego muestra un error amable.»
«¿Dónde se guardan los contadores de límite? ¿Seguirán funcionando si la app se ejecuta en más de una máquina?»
«Registra cada vez que un usuario o una IP alcance un límite, para poder detectar abusos.»
«¿Qué servicios externos llama esta app y cuáles son sus límites de frecuencia?»

Rate limiting en Mythex

La documentación de Mythex es clara sobre esto en las funciones de IA: los límites de frecuencia, la seguridad y los controles de coste de las apps que creas son cosa tuya; consulta Crear una app de IA. Pide al agente que añada límites en el mismo mensaje en el que pides la función. En el plan Pro, un servicio publicado puede ejecutarse en hasta tres máquinas cuando hay mucho tráfico (consulta Límites de alojamiento), así que pide contadores que vivan en la base de datos y no en la memoria de un solo servidor.

Lectura relacionada: qué es una API, cómo usar las APIs de LLM y la lista de seguridad para apps creadas con IA.

Preguntas

¿Qué es el rate limiting en pocas palabras?

Es una regla que limita cuántas peticiones puede hacer un usuario, un dispositivo o una app en un periodo determinado; por ejemplo, 5 intentos de inicio de sesión por minuto o 100 llamadas a la API por hora. Las peticiones que superan el límite se rechazan hasta que se reinicia la ventana de tiempo.

¿Qué significa el error 429 Too Many Requests?

El código de estado HTTP 429 indica que has enviado demasiadas peticiones en muy poco tiempo y has alcanzado un límite de frecuencia. La respuesta suele incluir una cabecera Retry-After que indica cuánto esperar. La solución es ir más despacio, reintentar tras una pausa o reducir la frecuencia con la que tu app llama al servicio.

¿Por qué mi app con IA necesita rate limiting?

Cada petición de IA te cuesta dinero en tokens. Sin un límite, un usuario o un bot puede enviar miles de peticiones, disparar una factura grande o agotar la cuota de tu proveedor, y dejar la función fuera de servicio para todos. Los límites por usuario mantienen los costes previsibles.

¿El rate limiting es lo mismo que el throttling?

Están muy relacionados y a menudo se usan como sinónimos. El rate limiting suele significar rechazar las peticiones que superan un límite, mientras que el throttling también puede significar ralentizarlas o ponerlas en cola en lugar de rechazarlas directamente.

¿El rate limiting detiene los ataques DDoS?

Ayuda frente a pequeñas avalanchas y abusos de usuarios individuales o de direcciones IP, pero un ataque distribuido grande llega desde muchas direcciones a la vez. La protección frente a esos ataques suele hacerse en el nivel de red o de CDN, antes de que el tráfico llegue a tu app.