¿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 tiempo determinado, por ejemplo 5 intentos de inicio de sesión por minuto o 100 llamadas a la API por hora. Cuando se alcanza el límite, las peticiones siguientes se rechazan (normalmente con el código de error 429 Too Many Requests) hasta que se reinicie la ventana de tiempo. Protege las apps frente al abuso, evita que un usuario muy intensivo ralentice el servicio para todos y frena los costes descontrolados.
El rate limiting se ve desde dos lados: los servicios que llamas te limitan a ti, y tu propia app debería limitar a sus usuarios.
Por qué importa cuando creas 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 una función de presupuesto.
- Control de costes. Si tu app tiene un cuadro de «pregunta 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 inviable.
- Seguir en línea. Un script que se comporta mal (a veces, tu propio código atascado en un bucle) puede sobrecargar la base de datos y tumbar la app.
- Respetar los límites de otros servicios. Si tu app llama con demasiada frecuencia a una API externa, tú recibes los errores 429 y las funciones fallan para tus usuarios.
Los creadores con IA construyen 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 rellenos gratis de una cafetería: «Un relleno 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 un cuarto relleno, el camarero dice amablemente «ahora no»: eso es el
429.
Un buen límite es invisible para los clientes normales y solo lo nota quien hace algo fuera de lo normal.
Cómo funciona el rate limiting
Un limitador de peticiones necesita tres cosas:
| 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 recuento de ese «quién». Por debajo del límite: la petición pasa y el recuento sube. Por encima del límite: la petición se rechaza.
Hay algunas formas habituales de contar:
| Método | Cómo funciona | Compromiso |
|---|---|---|
| Ventana fija | El recuento se reinicia según el reloj, por ejemplo cada minuto en punto | Sencillo, pero permite una ráfaga en el borde de 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 ritmo constante; cada petición gasta un token | Permite ráfagas cortas manteniendo estable la media |
Los recuentos deben guardarse en algún sitio rápido y compartido. En un servidor pequeño, la memoria sirve. Cuando una app funciona 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 se multiplica.
Cómo es una respuesta limitada
Cuando una petición supera el límite, una API bien diseñada responde con:
- Código de estado
429 Too Many Requests. - A menudo una cabecera
Retry-After, que indica cuántos segundos esperar. - En ocasiones, 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 después de cada intento fallido (1 segundo, luego 2, luego 4) en lugar de martillear el servicio.
Un ejemplo práctico: un asistente de redacción con IA
Imagina una app en la que los usuarios pegan un texto y reciben una reescritura hecha con 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 propio del proveedor, así que los usuarios reales ven errores toda la mañana.
Con límites sensatos:
- 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. Vuelve a intentarlo 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 así esquiven el límite por usuario.
- Un tope 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 del tipo «Estamos ocupados, 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, lo puede saltar cualquiera que llame directamente a tu API.
Términos clave
| Término | Significado |
|---|---|
| Rate limit | Número máximo de peticiones permitidas en una ventana de tiempo. |
| Cuota | Una asignación mayor, a menudo por día o mes, a veces ligada a un plan de pago. |
| 429 | Código de estado HTTP para «demasiadas peticiones». |
| Retry-After | Cabecera de respuesta que indica cuánto esperar antes de volver a intentarlo. |
| Throttling | Ralentizar o rechazar las peticiones que superan un límite. Se usa a menudo como sinónimo. |
| Backoff exponencial | Esperar cada vez más 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 es solo para apps grandes». Las apps pequeñas también son objetivo, porque los bots escanean internet buscando formularios y endpoints de IA abiertos. 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 IP: una oficina, un colegio, una red móvil. Los límites por usuario son más justos una vez que la gente ha iniciado sesión.
- «Un 429 significa que el servicio está roto». Significa que lo llamas con demasiada frecuencia. Revisa tu código por si hay bucles, y guarda en caché los resultados que cambian poco; consulta qué es la caché.
- «El rate limiting sustituye al tope de gasto». Usa ambos. Los límites de tu app pueden tener errores; el tope de gasto del proveedor es tu red de seguridad.
Qué pedir a tu creador de apps con IA
- «Añade rate limiting en el servidor para el inicio de sesión, el registro, el restablecimiento de contraseña y el endpoint de IA. Propón límites sensatos.»
- «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 un 429, reintenta con backoff exponencial hasta 3 veces y después muestra un error amable.»
- «¿Dónde se guardan los contadores de límites? ¿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.»
- «¿A qué servicios externos llama esta app y cuáles son sus límites de peticiones?»
Rate limiting en Mythex
La documentación de Mythex es clara sobre esto en las funciones de IA: los límites de peticiones, la seguridad y los controles de coste de las apps que creas son cosa tuya y los diseñas tú; consulta Crear una app con IA. Pide al agente que añada los límites en el mismo mensaje en el que pides la función. En Pro, un servicio publicado puede ejecutarse en hasta tres máquinas cuando el tráfico es alto (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 API de LLM y la lista de comprobación de seguridad para apps creadas con IA.
Preguntas
¿Qué es el rate limiting en pocas palabras?
El rate limiting 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 estado HTTP 429 significa que has enviado demasiadas peticiones en muy poco tiempo y has alcanzado un límite de peticiones. 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 a la IA te cuesta dinero en tokens. Sin un límite, un solo usuario o un bot puede enviar miles de peticiones, disparar la factura o agotar la cuota de tu proveedor, y dejar la función caída 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 oleadas pequeñas y frente al abuso de usuarios individuales o de direcciones IP concretas, pero un ataque distribuido grande llega desde muchas direcciones a la vez. La protección frente a esos ataques suele aplicarse en la red o en la CDN, antes de que el tráfico llegue a tu app.