API Gateway y Rate Limiting para tu App Web a Medida

Por qué tu aplicación web necesita un API gateway con rate limiting

Cada endpoint que expones es una puerta. Algunas reciben tráfico legítimo; otras acaban siendo el camino más corto para un atacante o para un cliente mal escrito que dispara mil peticiones en bucle. Un API gateway centraliza ese control: filtra peticiones, gestiona autenticación y aplica políticas de rate limiting antes de que nada toque a tus servicios internos.

Esto lo he visto fallar varias veces sin esa capa intermedia. Un bot raspando un endpoint público durante una madrugada, un cliente móvil con un retry mal configurado que multiplica la carga por veinte, o directamente miles de peticiones por segundo contra el login. El rate limiting pone un techo cuantificable y convierte un problema impredecible en uno que puedes medir y ajustar.

La combinación de gateway y limitación de tasa no es algo reservado a grandes corporaciones. Cualquier aplicación con una API REST o GraphQL expuesta se beneficia, sea cual sea su tamaño.

Componentes clave de un API gateway

Enrutamiento y balanceo de carga

El gateway recibe todas las peticiones y las dirige al microservicio que toque. Herramientas como Kong, AWS API Gateway o Traefik permiten definir rutas declarativas donde cada path (pongamos /api/v1/pedidos) apunta a un upstream distinto. Cuando hay varias instancias del mismo servicio, el gateway reparte carga con round-robin, least connections o algoritmos ponderados.

Autenticación y autorización centralizadas

En vez de que cada servicio valide tokens JWT o claves API por su cuenta, el gateway lo hace una sola vez en la entrada. Kong tiene plugins como jwt y key-auth que rechazan peticiones no autenticadas antes de que consuman recursos internos. AWS API Gateway permite enganchar un authorizer Lambda contra tu proveedor de identidad (Cognito, Auth0 o el tuyo propio).

Transformación de peticiones y respuestas

A veces toca tocar cabeceras, reescribir paths o adaptar formatos entre lo que el cliente espera y lo que devuelve el backend. Hacerlo en el gateway evita tocar el código de los servicios y reduce el acoplamiento. Cuando hay que retirar una versión vieja de la API, ese trabajo se nota.

Observabilidad

Un gateway bien configurado emite métricas (latencia, tasa de errores, volumen por endpoint) hacia Prometheus, Datadog o CloudWatch. Esas métricas son la base para ajustar los umbrales de rate limiting con datos reales, no con suposiciones del tipo "esto debería bastar".

Algoritmos de rate limiting: cuál elegir y cuándo

No todos los algoritmos se comportan igual. El adecuado depende del patrón de tráfico que recibes y del nivel de protección que buscas.

Token bucket

Cada cliente tiene un cubo con un número fijo de tokens. Cada petición consume uno, y se regeneran a una tasa constante. Si el cubo se vacía, las siguientes peticiones se rechazan hasta que vuelva a haber tokens.

La ventaja es que permite ráfagas breves de tráfico legítimo —el típico usuario que carga varias secciones a la vez— sin penalizarlo. Es lo que Kong usa por defecto en su plugin rate-limiting.

Caso concreto: configuras 100 tokens con regeneración de 10 por segundo. Un cliente puede disparar 100 peticiones de golpe, pero a partir de ahí solo mantendrá 10 por segundo sostenidas.

Sliding window log

Registra el timestamp de cada petición dentro de una ventana deslizante (por ejemplo, los últimos 60 segundos). Si el número de entradas supera el umbral, la petición se cae.

Es más preciso que la ventana fija porque elimina el problema del borde, donde un cliente puede duplicar su cuota colando peticiones justo antes y después del cambio de ventana.

Pesa en memoria, eso sí: guarda cada timestamp uno a uno. Encaja bien cuando tienes pocos clientes con requisitos estrictos de equidad.

Sliding window counter

Mezcla la eficiencia de la ventana fija con la precisión de la deslizante. Mantiene contadores para la ventana actual y la anterior, y pondera el resultado según el porcentaje de tiempo transcurrido.

Es lo que Cloudflare implementa en su servicio de rate limiting, y suele ser el equilibrio más cómodo entre precisión y consumo de recursos.

Fixed window counter

El más sencillo: cuenta peticiones por intervalos fijos (de minuto en minuto, por ejemplo) y rechaza cuando se pasa del límite. Fácil de implementar, gasta poca memoria, pero arrastra el problema del borde de ventana. Sirve para protecciones básicas donde la precisión milimétrica da igual.

Diseño de la estrategia: de la teoría a la configuración

Paso 1: identifica tus endpoints críticos

No todos necesitan el mismo nivel de protección. Clasifícalos en tres grupos:

• Alta sensibilidad: login, registro, recuperación de contraseña, endpoints de pago. Aquí el límite tiene que ser estricto, del orden de 5 intentos de login por minuto por IP.
• Sensibilidad media: consultas que pegan contra base de datos (listados, búsquedas). 60-120 peticiones por minuto por usuario autenticado suele ser razonable.
• Baja sensibilidad: recursos estáticos o health checks. Aquí puedes ser más generoso o directamente excluirlos.

Paso 2: define las dimensiones del límite

Puedes limitar por IP, por usuario autenticado, por clave API o por combinaciones. Limitar solo por IP es problemático cuando varios usuarios comparten la misma (redes corporativas, NAT carrier-grade): un día empiezas a bloquear oficinas enteras sin darte cuenta. Limitar solo por usuario autenticado es más fino, pero no protege el login, donde el atacante aún no tiene sesión.

La estrategia más sólida combina ambas: rate limiting por IP en endpoints públicos (login, registro) y por usuario autenticado en los que ya están detrás de auth.

Paso 3: elige tu infraestructura

Kong (open source o Enterprise): encaja bien si ya tienes microservicios on-premise o en contenedores. Su plugin rate-limiting soporta políticas local, cluster y Redis. La de Redis es la única realmente fiable en entornos distribuidos, porque centraliza los contadores y todos los nodos ven lo mismo.

Configuración mínima en Kong con YAML declarativo:

plugins:
  - name: rate-limiting
    config:
      minute: 60
      policy: redis
      redis_host: redis.internal
      redis_port: 6379

AWS API Gateway: si tu stack vive en AWS, el servicio gestionado ya trae throttling con dos niveles: tasa sostenida (steady-state rate) y ráfaga (burst). El default son 10.000 peticiones por segundo con ráfagas de 5.000, pero puedes crear Usage Plans con claves API para definir cuotas por cliente.

Traefik: habitual en entornos Kubernetes. Su middleware rateLimit usa token bucket y se configura desde anotaciones de Ingress o ficheros TOML/YAML.

http:
  middlewares:
    rate-limit:
      rateLimit:
        average: 50
        burst: 100
        period: 1m

Paso 4: define las respuestas ante exceso de cuota

Cuando un cliente pasa del límite, el gateway debe devolver un 429 (Too Many Requests) con cabeceras informativas:

• Retry-After: segundos hasta que el cliente puede volver a intentarlo.
• X-RateLimit-Limit: el límite configurado.
• X-RateLimit-Remaining: peticiones que quedan en la ventana actual.
• X-RateLimit-Reset: timestamp en que se reinicia la ventana.

Con estas cabeceras, un cliente bien escrito adapta su comportamiento solo, con backoff exponencial. Sin ellas, lo típico es que reintente en bucle y agrave el problema; lo he visto con un SDK móvil que provocó una caída en cadena precisamente por ignorar el Retry-After.

Paso 5: monitoriza y ajusta

Los umbrales iniciales son una hipótesis. Tras el despliegue, mira las métricas durante al menos dos semanas y responde a estas preguntas:

• ¿Qué porcentaje de peticiones legítimas están cayendo con 429? Si pasa del 1-2%, los límites están demasiado apretados.
• ¿Hay IPs que agotan su cuota de forma sistemática? Suelen ser bots y conviene bloquearlos a nivel de WAF.
• ¿Los picos coinciden con campañas de marketing o con patrones de ataque?

Grafana con dashboards conectados a Prometheus hace el trabajo cómodo. Configura alertas cuando la tasa de 429 supere un umbral; reaccionar tarde a esto sale caro.

Errores frecuentes al implementar rate limiting

Aplicar el mismo límite a todos los endpoints. Un buscador que devuelve datos cacheados no necesita el mismo umbral que un endpoint que dispara una transacción bancaria. La granularidad importa más de lo que parece al principio.

No contemplar la persistencia de contadores en entornos distribuidos. El problema típico que aparece a los seis meses es este: el gateway corre en varios nodos, cada uno mantiene su contador en memoria local, y un cliente acaba multiplicando su cuota real por el número de nodos. Redis o una base de datos compartida resuelven el asunto.

Olvidar los endpoints internos. Si el gateway protege solo lo público y deja la comunicación entre microservicios al desnudo, basta con que uno se vea comprometido para que tumbe a los demás. Aplica rate limiting también en la malla interna, aunque con umbrales más holgados.

No documentar la política. Tus consumidores de API —equipos internos, partners o clientes— necesitan conocer los límites para diseñar sus integraciones. Publica umbrales, cabeceras de respuesta y recomendaciones de retry en la documentación. Si no lo haces, lo descubrirán a base de incidencias.

Cómo escalar la protección más allá del rate limiting

El rate limiting es una primera línea de defensa, no la única. Para una protección completa, combínalo con:

• WAF (Web Application Firewall): filtra ataques de capa de aplicación (SQL injection, XSS) antes incluso de que lleguen al gateway. AWS WAF, Cloudflare WAF o ModSecurity son los habituales.
• Circuit breaker en los servicios backend: si un servicio empieza a degradarse, el circuit breaker (con librerías como Resilience4j o Hystrix) corta el tráfico hacia él y devuelve respuestas degradadas en lugar de propagar el fallo aguas arriba.
• Caché en el gateway: para endpoints de lectura frecuente, cachear las respuestas baja la carga del backend y reduce la superficie de ataque. Kong y AWS API Gateway soportan caché nativa con TTL configurable.

Siguiente paso para blindar tu API

Diseñar una estrategia de API gateway con rate limiting no se resuelve instalando una herramienta. Hay que entender la arquitectura, mirar los patrones de tráfico reales y conocer los riesgos del negocio. Después toca configurarla con criterio, observarla y reajustarla cada cierto tiempo.

Si quieres echar una mano para diseñar esta capa en tu aplicación a medida, o auditar una arquitectura que ya tienes en producción, puedes escribirnos y lo miramos juntos sin compromiso.