Rate Limiting

Definición

Imagina un buffet de todo lo que puedas comer. Sin reglas, una persona podría acumular platos de comida mientras otros esperan hambrientos. Por eso los buffets a veces limitan cuántas veces puedes ir a ciertas estaciones. El rate limiting es la misma idea para las APIs - controla cuántas peticiones puede hacer un usuario o sistema en un período de tiempo dado.

¿Por qué molestarse en limitar peticiones? Varias razones. Primero, protección de recursos - tus servidores solo pueden manejar cierto tráfico antes de volverse lentos o colapsar. Segundo, equidad - sin límites, un único cliente podría acaparar todos tus recursos mientras otros sufren. Tercero, seguridad - los atacantes a menudo intentan sobrecargar sistemas con peticiones (ataques DDoS) o forzar contraseñas con miles de intentos. El rate limiting hace que estos ataques sean poco prácticos.

Típicamente verás límites como “100 peticiones por minuto” o “1000 llamadas por día.” Cuando alcanzas el límite, la API responde con un código de estado 429 (Too Many Requests) y a menudo te dice cuánto tiempo esperar antes de intentar de nuevo. Diferentes usuarios podrían obtener diferentes límites - los planes gratuitos obtienen menos, los clientes premium obtienen más, y los sistemas internos podrían no tener límites en absoluto.

Ejemplo

APIs de Redes Sociales: La API de Twitter limita ciertas peticiones a 15 por ventana de 15 minutos. Esto previene que los bots exfiltren datos de usuarios o spameen la plataforma. Si tu herramienta de analítica de tweets alcanza el límite, espera al siguiente período de ventana antes de continuar.

Protección de Intentos de Login: Las páginas de login típicamente permiten 5 intentos fallidos antes de bloquearte temporalmente. Esto previene que los atacantes prueben miles de combinaciones de contraseñas. Cada intento fallido acerca al usuario al límite; el éxito resetea el contador.

APIs de Mapas: Google Maps API te da una cantidad de peticiones gratuitas por mes. Supera eso, y empiezas a pagar - o tu aplicación deja de funcionar. Esto asegura que la aplicación de prueba de algún desarrollador no le cueste accidentalmente a Google millones en recursos de mapas.

APIs de Gateways de Pago: Stripe limita las llamadas a su API para prevenir abusos y asegurar la estabilidad del servicio. Si estás haciendo pruebas de integración ejecutando cientos de transacciones de prueba por minuto, alcanzarás límites diseñados para detener patrones de uso problemáticos.

APIs de Servicios del Tiempo: Las APIs del tiempo gratuitas podrían permitir 60 llamadas por minuto. Si estás construyendo una aplicación del tiempo que sondea cada segundo, alcanzarás ese límite en un minuto y empezarás a obtener errores. El diseño correcto es cachear las respuestas y sondear con menos frecuencia.

Analogía

El Control del Buffet: Un restaurante buffet tiene reglas implícitas - solo un viaje a la barra de mariscos a la vez, máximo dos platos por visita. Esto asegura que todos tengan acceso a los mariscos premium, no solo los primeros diez clientes. El rate limiting hace cumplir las mismas reglas de equidad para el acceso a la API.

Límite de Libros de la Biblioteca: Puedes sacar 10 libros a la vez de la biblioteca. Esto previene que una persona acapare todos los libros populares. Si quieres más, devuelve algunos primero. Las APIs funcionan igual - hay un límite de peticiones “activas” que puedes hacer, asegurando que los recursos se compartan equitativamente.

Semáforos de Acceso a Autopista: Durante las horas pico, las rampas de autopista usan semáforos para limitar cuántos coches entran a la autopista por minuto. Esto previene que la autopista se sature y el tráfico se detenga por completo. El rate limiting mantiene tu “autopista de API” fluyendo suavemente en lugar de permitir un tráfico de ráfaga que colapse todo.

El Contador del Portero: Los porteros de clubes nocturnos usan contadores de mano para rastrear la ocupación. Cuando se alcanza la capacidad, la gente espera en fila hasta que otros se van. No se trata de ser exclusivo - se trata de la seguridad y la experiencia del cliente adentro. El rate limiting gestiona la “ocupación” de la API de la misma manera.

Code Example

// Middleware de rate limiting con ventana deslizante
const rateLimiter = new Map<string, number[]>();
const WINDOW_MS = 60000; // 1 minuto
const MAX_REQUESTS = 100;

function rateLimit(req: Request, res: Response, next: Function) {
  const clientId = req.ip;
  const now = Date.now();

  // Obtener peticiones del cliente en la ventana actual
  const requests = rateLimiter.get(clientId) || [];
  const windowStart = now - WINDOW_MS;

  // Filtrar peticiones fuera de la ventana
  const recentRequests = requests.filter(time => time > windowStart);

  if (recentRequests.length >= MAX_REQUESTS) {
    res.status(429).json({
      error: 'Too Many Requests',
      retryAfter: Math.ceil((recentRequests[0] + WINDOW_MS - now) / 1000)
    });
    return;
  }

  recentRequests.push(now);
  rateLimiter.set(clientId, recentRequests);

  // Añadir cabeceras de límite de tasa
  res.setHeader('X-RateLimit-Limit', MAX_REQUESTS);
  res.setHeader('X-RateLimit-Remaining', MAX_REQUESTS - recentRequests.length);

  next();
}

Notas de Seguridad