Throttling

Definition

Throttling es un mecanismo de control de tráfico que regula la tasa de solicitudes de API retrasando o encolando el exceso de solicitudes en lugar de rechazarlas directamente. A diferencia del rate limiting, que actúa como una barrera dura (llegas al límite, estás bloqueado), el throttling actúa más como un semáforo - reduce la velocidad del flujo para mantener todo moviéndose suavemente. Asegura que ningún cliente único abrume tu sistema mientras mantiene la disponibilidad del servicio.

La diferencia clave entre throttling y rate limiting está en cómo manejan el tráfico excesivo. Rate limiting dice “has usado tus 100 solicitudes por minuto, vuelve más tarde”. Throttling dice “estás haciendo solicitudes demasiado rápido, las procesaré pero más lento”. Esto hace que el throttling se sienta menos abrupto para los usuarios mientras protege tu infraestructura.

El throttling es esencial para mantener la estabilidad del sistema bajo carga variable. Durante picos de tráfico, previene fallos en cascada aplicando contrapresión - reduciendo la velocidad de clientes upstream cuando servicios downstream no pueden seguir el ritmo. Es como tener un buffer inteligente que se adapta a la capacidad del sistema en tiempo real.

Example

Servicios de Streaming de Video: YouTube hace throttling de descargas de video basándose en tu velocidad de visualización. Si estás mirando a velocidad normal, descarga por adelantado pero para de bufferear cuando tiene suficiente. Esto previene que usuarios descarguen películas enteras cuando solo verán 5 minutos, ahorrando ancho de banda para otros.

Subida de Almacenamiento en la Nube: Dropbox hace throttling de subidas grandes durante horas pico. En lugar de rechazar tu carpeta de 50GB, encola los archivos y los procesa a una tasa controlada. Ves progreso, solo que más lento que durante horas valle. Esto mantiene el servicio responsivo para todos.

Procesadores de Pagos: Stripe hace throttling de operaciones de pago masivas. Si intentas procesar 10,000 pagos de una vez, aceptarán el lote pero lo procesarán a una tasa controlada (quizás 100/segundo) para prevenir sobrecarga de sus sistemas de detección de fraude. Todos los pagos eventualmente se procesan, solo que no todos a la vez.

API Gateway Durante Pico de Tráfico: Durante una campaña de marketing viral, tu API podría recibir 100x el tráfico normal. En lugar de colapsar, el gateway hace throttling de solicitudes entrantes para coincidir con la capacidad de tu backend (quizás 1000 req/seg). Las solicitudes se encolan, los usuarios ven respuestas más lentas (2-3 segundos en lugar de 200ms), pero el servicio permanece en línea.

Pool de Conexiones de Base de Datos: Cuando tu aplicación recibe una oleada de tráfico, el pool de conexiones hace throttling de consultas a la base de datos. En lugar de abrir 10,000 conexiones simultáneas (lo que colapsaría la BD), mantiene un pool fijo (quizás 100 conexiones) y encola el resto. Cada consulta espera su turno, previniendo el colapso del sistema.

Analogy

El Carril de Fusión en la Autopista: Cuando una autopista se estrecha de 3 carriles a 1, los autos no chocan ni son rechazados. Hacen throttling - fusionándose uno por uno de manera controlada. El tráfico se ralentiza, pero todos eventualmente pasan. Sin throttling, tendrías bloqueo total o accidentes.

La Cocina del Restaurante: Durante una cena ocupada, la cocina no rechaza reservas. En su lugar, hacen throttling del servicio - aceptando órdenes pero pausando la cocción para coincidir con la capacidad del chef. Los clientes esperan más por la comida, pero todos son servidos. La alternativa (intentar cocinar todo a la vez) resultaría en caos y comida quemada.

La Fila de Caja: Una tienda no cierra cuando se forma una fila. Los clientes hacen fila y pasan por caja al ritmo natural del cajero (throttling). La fila se hace más larga durante picos, pero todos esperan su turno. Si intentaran procesar a todos simultáneamente, sería un caos.

El Regulador de Presión de Agua: Cuando muchas personas abren grifos simultáneamente, un regulador de presión hace throttling del flujo de agua para prevenir daño a las tuberías. Todos aún obtienen agua, solo que a una tasa controlada. Sin throttling, la caída súbita de presión podría reventar tuberías.

Code Example

// Throttling del lado del cliente con backoff
class ThrottledAPIClient {
  constructor(maxRequestsPerSecond = 10) {
    this.maxRPS = maxRequestsPerSecond;
    this.requestQueue = [];
    this.processing = false;
  }

  async request(url, options) {
    return new Promise((resolve, reject) => {
      this.requestQueue.push({ url, options, resolve, reject });
      this.processQueue();
    });
  }

  async processQueue() {
    if (this.processing || this.requestQueue.length === 0) return;

    this.processing = true;
    const delayBetweenRequests = 1000 / this.maxRPS;

    while (this.requestQueue.length > 0) {
      const { url, options, resolve, reject } = this.requestQueue.shift();

      try {
        const response = await fetch(url, options);

        // Servidor indica throttling
        if (response.status === 429) {
          const retryAfter = response.headers.get('Retry-After') || 5;
          console.log(`Throttled por servidor. Esperando ${retryAfter}s...`);
          await new Promise(r => setTimeout(r, retryAfter * 1000));

          // Re-encolar la solicitud
          this.requestQueue.unshift({ url, options, resolve, reject });
          continue;
        }

        resolve(response);
      } catch (error) {
        reject(error);
      }

      // Throttle: esperar antes de la siguiente solicitud
      await new Promise(r => setTimeout(r, delayBetweenRequests));
    }

    this.processing = false;
  }
}

// Uso
const client = new ThrottledAPIClient(10); // máximo 10 solicitudes/segundo

// Hacer 100 solicitudes - serán throttled automáticamente
for (let i = 0; i < 100; i++) {
  client.request('/api/data', { method: 'GET' })
    .then(res => res.json())
    .then(data => console.log(`Solicitud ${i} completada`));
}

Diagram

graph TB
    subgraph Client["Aplicación Cliente"]
        C1[Solicitud 1]
        C2[Solicitud 2]
        C3[Solicitud 3]
        C4[Solicitud N...]
    end

    subgraph Throttle["Capa de Throttling
(API Gateway)"]
        Q[Cola de Solicitudes]
        R[Controlador de Tasa
100 req/seg]
        M[Monitor de Carga del Backend]
    end

    subgraph Backend["Servicios Backend"]
        B1[Instancia de Servicio 1]
        B2[Instancia de Servicio 2]
        DB[(Base de Datos)]
    end

    C1 --> Q
    C2 --> Q
    C3 --> Q
    C4 --> Q

    Q --> R
    M -.Verificar Capacidad.-> B1
    M -.Verificar Capacidad.-> B2
    M -.Ajustar Tasa.-> R

    R -->|Flujo Controlado
100 req/seg| B1
    R -->|Flujo Controlado
100 req/seg| B2
    B1 --> DB
    B2 --> DB

    style Q fill:#fff4e6
    style R fill:#ffe6e6
    style M fill:#e6f3ff
    style Throttle fill:#f0f0f0

Security Notes

Best Practices

1. Capas de Defensa: Combinar throttling (suaviza tráfico) con rate limiting (topes duros) y circuit breakers (falla rápido cuando downstream está caído)
2. Throttling Adaptativo: Ajustar tasa de throttle basándose en capacidad de backend en tiempo real, no solo configuración estática
3. Gestión de Cola: Establecer tamaños máximos de cola para prevenir agotamiento de memoria. Mejor rechazar que encolar para siempre
4. Comunicación Transparente: Usar headers Retry-After y códigos de estado 429 para decir a clientes cuándo pueden reintentar
5. Throttling Por Recurso: Diferentes endpoints tienen diferentes costos. Hacer throttle más agresivo de operaciones costosas (búsquedas, reportes) que de operaciones baratas (datos estáticos)
6. Priorizar Tráfico: Dar mayor prioridad a usuarios autenticados sobre anónimos, o tiers pagados sobre gratuitos
7. Degradación Elegante: Al hacer throttling, considerar retornar datos en caché/obsoletos en lugar de hacer esperar a clientes
8. Monitorear y Alertar: Rastrear tasas de throttle, profundidades de cola y tasas de rechazo. Alertar cuando los umbrales excedan patrones normales

Common Mistakes

No Distinguir Throttling de Rate Limiting: Los equipos a menudo confunden ambos. Rate limiting es una parada dura (403/429), throttling es ralentización intencional (encolamiento, retardo). Usar ambos juntos para mejores resultados.

Throttling Solo del Lado del Cliente: Confiar en que los clientes se hagan throttling a sí mismos es ingenuo. Actores maliciosos lo evitarán. Siempre aplicar del lado del servidor.

Colas Infinitas: Encolar solicitudes sin tamaño máximo de cola lleva al agotamiento de memoria. Establecer límites y rechazar cuando esté lleno.

Sin Header Retry-After: Al hacer throttling, siempre decir a clientes cuándo reintentar. Sin orientación, martillarán tu API con reintentos.

Tasas de Throttle Fijas: Tasas de throttle estáticas (siempre 100 req/seg) no se adaptan a carga cambiante. Usar throttling dinámico basado en salud del backend.

Throttling de Endpoints de Autenticación: Tener cuidado al hacer throttle de login/signup. Demasiado agresivo y usuarios legítimos no pueden acceder a tu servicio. Demasiado permisivo y eres vulnerable a fuerza bruta.

Sin Diferenciación: Hacer throttle de todo el tráfico por igual trata un ataque DDoS igual que un cliente premium. Implementar throttling escalonado.

Registrar Cada Solicitud Throttled: Throttling genera altos volúmenes de eventos. Registrar muestras o agregados, no cada solicitud throttled, o abrumarás tu sistema de logging.

Standards & RFCs

Related Terms