¿Error 429 en APIs Node.js? Cómo implementar Rate Limiting

Por qué tu servidor Node.js necesita control de tráfico

Imagina que abres una cafetería popular y una sola persona decide entrar al local cada segundo para pedir un vaso de agua gratis. En pocos minutos, la fila impide que los clientes reales compren café y la caja registradora colapsa. En el universo de las APIs, esta situación ocurre cuando bots, scripts mal escritos o ataques de fuerza bruta inundan una aplicación con miles de accesos simultáneos.

Cuando el servidor no puede procesar tanta demanda, se cae, interrumpiendo el servicio para todos los usuarios legítimos. Exactamente para evitar este caos utilizamos el Rate Limiting, un mecanismo de control que limita cuántas veces una dirección puede llamar a una ruta en un intervalo específico. Cuando se supera el límite, la aplicación responde con el famoso error 429 Too Many Requests.

Muchos equipos intentan resolver esto guardando contadores directamente en la memoria RAM del proceso Node.js. Aunque funciona para pruebas sencillas, este enfoque falla miserablemente en entornos modernos donde escalamos la aplicación en múltiples contenedores o servidores. Si la petición A cae en el servidor uno y la petición B cae en el servidor dos, pierden la cuenta conjunta, abriendo brechas para abusos.

Cómo Redis resuelve el control de tasa a gran escala

Para mantener el seguimiento de peticiones sincronizado entre distintas instancias de tu API, necesitamos una fuente de verdad centralizada, rápida y volátil. Aquí es donde entra Redis, un almacenamiento de datos en memoria conocido por su velocidad extrema y su capacidad para expirar claves automáticamente tras unos segundos.

En la práctica, cada vez que un usuario realiza una solicitud, la API incrementa un contador atómico en Redis asociado a la dirección IP de ese visitante. Si el contador supera el umbral establecido, la aplicación bloquea la ejecución de inmediato. Redis gestiona estas operaciones en fracciones de milisegundo, asegurando que la verificación de seguridad no añada latencia perceptible al sistema.

Antes de implementar reglas complejas de tráfico, vale la pena asegurar que otros aspectos de infraestructura de tu API estén afinados, como resolver problemas comunes de configuración de CORS en Express para evitar bloqueos indeseados en el navegador. Con una base limpia, puedes estructurar la lógica del limitador sin interferir con peticiones legítimas de orígenes confiables.

Implementando Rate Limiting con Express y Redis en la práctica

Para ponernos manos a la obra, vamos a construir un middleware en Node.js usando el framework Express junto con la librería ioredis. El objetivo es interceptar las llamadas entrantes, consultar Redis para verificar cuántas veces ese IP accedió al endpoint en los últimos sesenta segundos y decidir si la puerta permanece abierta o cerrada.

Primero, instalamos los paquetes necesarios en la terminal del proyecto usando el gestor de dependencias. A continuación, configuramos la conexión con el servidor Redis y escribimos la lógica de conteo incremental con tiempo de expiración automático configurado por clave de IP.

const express = require('express');const Redis = require('ioredis');const app = express();const redis = new Redis();const WINDOW_SIZE_IN_SECONDS = 60;const MAX_REQUESTS = 10;app.use(async (req, res, next) => {  const ip = req.ip;  const key = `rate-limit:${ip}`;  try {    const requests = await redis.incr(key);    if (requests === 1) {      await redis.expire(key, WINDOW_SIZE_IN_SECONDS);    }    if (requests > MAX_REQUESTS) {      return res.status(429).json({        error: 'Demasiadas solicitudes. Intente nuevamente más tarde.'      });    }    next();  } catch (error) {    console.error('Error en el rate limiter:', error);    next();  }});app.get('/api/datos', (req, res) => {  res.json({ mensaje: '¡Acceso concedido con éxito!' });});app.listen(3000, () => {  console.log('Servidor corriendo en el puerto 3000');});

Este código sencillo pero robusto garantiza que cualquier IP que supere diez solicitudes dentro de una ventana de un minuto reciba una respuesta 429 instantánea. El secreto radica en el comando incr de Redis, que ejecuta la lectura y la suma de forma atómica, previniendo condiciones de carrera incluso bajo un alto volumen de accesos paralelos.

Trampas comunes y mejores prácticas en la configuración

Aunque la lógica básica funciona bien, los escenarios del mundo real exigen cuidados adicionales. Si tu aplicación está detrás de un proxy inverso, balanceador de carga o servicios en la nube como Cloudflare, la dirección IP real del cliente puede venir enmascarada en las cabeceras de la petición, como x-forwarded-for, en vez de aparecer directamente en el objeto de conexión de Express.

Para solucionar esto, es fundamental habilitar la propiedad trust proxy en Express para que la aplicación sepa leer correctamente el IP original del usuario. Otro punto crítico es definir mensajes de error claros y educativos en el cuerpo de la respuesta HTTP, acompañados opcionalmente por la cabecera Retry-After para orientar a clientes legítimos sobre cuándo reintentar.

En escenarios avanzados donde múltiples servicios comparten recursos sensibles de base de datos, el límite de tasa por IP puede complementarse con estrategias de aislamiento de conexiones o el uso de pool de conexiones eficientes para evitar cuellos de botella. Proteger la capa de transporte y la capa de datos en conjunto garantiza una resiliencia arquitectónica total. Para profundizar en estos conceptos arquitectónicos en producción, consulte también nuestro análisis técnico sobre Cómo probar pantalla LCD con multímetro en el banco.

Consideraciones finales sobre la resiliencia de APIs

Implementar control de tasa con Node.js y Redis es una de las defensas más eficaces y económicas que puedes añadir a una arquitectura de microservicios o monolitos modernos. Además de bloquear intentos maliciosos de rastreo y extracción de datos, esta estrategia protege tus servidores contra fallos en cascada generados por clientes atrapados en bucles infinitos.

Al adoptar esta práctica desde las etapas iniciales del desarrollo, garantizas previsibilidad operativa, proteges tus bases de datos contra picos anómalos de lectura y mejoras significativamente la experiencia de los usuarios que dependen de un sistema estable y siempre disponible.