Mi limitador de tasa hacía exactamente lo que le pedí. Ese era el problema.

Cuando implementamos un limitador de tasa en una API, solemos hacerlo con la mejor intención: proteger el sistema de abusos. Sin embargo, como he comprobado en varios proyectos, ese limitador puede estar resolviendo el problema equivocado. El enfoque más común —limitar por IP— asume que el cuello de botella está en nuestro propio servidor. Pero cuando nuestro backend consume APIs externas con cuotas por cuenta, el verdadero límite es compartido entre todos los usuarios, sin importar cuántas IPs diferentes estén haciendo solicitudes.

Imaginemos un endpoint que genera imágenes usando proveedores de inteligencia artificial. Cada proveedor impone un límite de, por ejemplo, 5 imágenes por minuto a nivel de cuenta. Nuestro limitador por IP, configurado a 3 peticiones por minuto, parece conservador. Pero cinco usuarios distintos, cada uno por debajo de su tope individual, pueden enviar 15 solicitudes en un minuto. El proveedor solo acepta 5. Las peticiones empiezan a fallar silenciosamente, no por un error del usuario sino por la suma de todos. Este problema no aparece en pruebas porque requiere un número mínimo de usuarios concurrentes. Aparece justo cuando más éxito tienes, en el peor momento posible.

La solución correcta consiste en implementar un contador global que refleje el techo real del proveedor, antes de realizar la llamada externa. En lugar de verificar cuántas veces ha llamado una IP, debemos comprobar cuántas llamadas se han hecho en total a ese proveedor en la ventana de tiempo. Si no hay capacidad, se rechaza la solicitud con un código claro y un tiempo de espera. Esto evita consumir recursos del proveedor en vano y da una experiencia predecible al usuario. En arquitecturas distribuidas, ese contador debe vivir en un sistema compartido como Redis, algo que los servicios cloud AWS y Azure facilitan enormemente.

En Q2BSTUDIO, al desarrollar aplicaciones a medida, entendemos que proteger un endpoint no es un acto único. Requiere analizar todas las dependencias externas: proveedores de IA, pasarelas de pago, servicios de mensajería. Cada integración tiene su propia lógica de límites, y nuestra capa de control debe reflejar esa realidad. No basta con copiar un middleware de ejemplo; hay que diseñar sistemas que escalen y que no se rompan cuando el negocio crece. Por eso, nuestros proyectos integran buenas prácticas de ciberseguridad, inteligencia de negocio y automatización.

La lección es clara: el rate limiting no es una talla única. Proteger contra un usuario abusivo es muy distinto a respetar una cuota compartida entre todos. Si tu empresa depende de APIs con límites por cuenta —como sucede con muchos servicios de ia para empresas o con agentes IA que consumen modelos externos— vale la pena revisar si tu limitador está realmente resolviendo el problema correcto. De lo contrario, estarás invirtiendo en una falsa sensación de seguridad mientras los fallos silenciosos se acumulan. En Q2BSTUDIO ofrecemos soluciones completas: desde software a medida hasta servicios inteligencia de negocio con Power BI, pasando por la implementación de agentes IA y la monitorización de cuotas en tiempo real. Porque un sistema bien diseñado no solo funciona, sino que lo hace de forma predecible incluso cuando la carga crece.