Rate limiting nativo: el contador por clave que no escribes

Limitar la tasa parece un ejercicio trivial: un contador, una ventana, un rechazo. Lo es en un servidor único con un diccionario en memoria. En el edge, donde tu código corre a la vez en cientos de ubicaciones sin memoria compartida, ese contador se convierte en un problema de consenso distribuido, y cualquier solución honesta te obliga a elegir qué sacrificar. El binding nativo de límite de tasa hace esa elección por ti y la hace de forma explícita: renuncia a la exactitud global para darte una comprobación local con coste próximo a cero. Entender por qué esa renuncia es sensata, y dónde deja de serlo, es toda la lección.

Las tres salidas y sus facturas

Antes de que existiera el binding, quien necesitaba limitar en el edge tenía tres caminos y ninguno gratis. El primero era KV: leer un contador, incrementarlo, escribirlo. Barato de leer, pero su consistencia es eventual, de modo que en el instante exacto de una ráfaga —justo cuando lo necesitas— el valor que lees está desactualizado y el atacante pasa mientras la propagación viaja.

El segundo camino era un Durable Object, que sí da un contador exacto porque toda la cuenta ocurre en un único hilo. El precio es de manual: ese objeto vive en un solo lugar del planeta, así que cada petición del mundo entero paga un salto de red hasta él antes de ser atendida, y has convertido tu defensa en el punto más lento y más frágil de tu sistema.

El tercer camino era no limitar en el Worker sino en la WAF, con reglas de tasa a nivel de zona. Sigue siendo una capa excelente y conviene tenerla, porque frena en la frontera sin gastar ni un milisegundo de tu CPU. Lo que no puede hacer es mirar dentro de tu lógica: no sabe qué usuario ha iniciado sesión, ni qué plan tiene contratado, ni si esta petición concreta es la quinta de un flujo caro.

El binding y su forma

Se declara en el manifiesto con un identificador de espacio, un límite y un periodo. El periodo admite dos valores, diez o sesenta segundos, y esa restricción no es un capricho: es lo que permite que el contador sea barato.

{
  "ratelimits": [
    {
      "name": "LIMITE_LOGIN",
      "namespace_id": "1001",
      "simple": { "limit": 5, "period": 60 }
    },
    {
      "name": "LIMITE_API",
      "namespace_id": "1002",
      "simple": { "limit": 100, "period": 60 }
    }
  ]
}

Declara un espacio por operación en lugar de uno solo compartido. El identificador de espacio separa los contadores, de modo que agotar el cupo del login no consume el de la API, y te permite afinar cada número por separado sin tocar los demás. Cambiar el límite o el periodo de un espacio en caliente es una decisión de despliegue, no de código: conviene tenerlo presente porque el ajuste fino de estos números ocurre siempre después de ver tráfico real, nunca antes.

El uso es una sola llamada que devuelve un objeto con success. No hay que incrementar nada a mano ni liberar nada después: la propia llamada cuenta.

export default {
  async fetch(request, env): Promise<Response> {
    const ip = request.headers.get("CF-Connecting-IP") ?? "desconocida";
    const { success } = await env.LIMITE_API.limit({ key: ip });

    if (!success) {
      return new Response("Demasiadas peticiones", {
        status: 429,
        headers: { "Retry-After": "60", "Cache-Control": "no-store" },
      });
    }

    return new Response("ok");
  },
} satisfies ExportedHandler<Env>;

El 429 merece cuidado. Acompáñalo siempre de Retry-After, porque es la única forma de que un cliente educado sepa esperar en vez de reintentar en bucle y agravar justo lo que intentabas frenar. Y no reveles en el mensaje cuánto le falta al atacante para volver a pasar.

Elegir la clave

La configuración es lo fácil. La clave es donde está el diseño, porque define a quién estás contando. Una clave demasiado amplia castiga a inocentes; una demasiado estrecha no detiene a nadie.

function clave(request: Request, usuario: { id: string } | null, operacion: string): string {
  const ip = request.headers.get("CF-Connecting-IP") ?? "sin-ip";
  const sujeto = usuario ? `u:${usuario.id}` : `ip:${ip}`;
  return `${operacion}:${sujeto}`;
}

const login = await env.LIMITE_LOGIN.limit({ key: clave(request, null, "login") });
const api = await env.LIMITE_API.limit({ key: clave(request, usuario, "api") });

Mantén las claves cortas y derivadas de datos que tú controlas. Una clave construida con una cabecera que el cliente escribe libremente no limita a nadie: basta con cambiarla en cada petición para tener un cupo nuevo cada vez.

flowchart TD
P[peticion] --> K[construir la clave]
K --> L[limit sobre el binding]
L -->|success verdadero| H[handler y logica cara]
L -->|success falso| R[429 con Retry After]
style R fill:#f38ba8,color:#11111b
style H fill:#a6e3a1,color:#11111b

Dónde deja de bastar

Un límite aproximado es la herramienta correcta para lo que constituye el noventa por ciento de los casos: contener fuerza bruta en el login, frenar bucles de clientes mal programados, poner un techo al gasto de un endpoint caro y evitar que un solo actor degrade el servicio de todos. En todos esos escenarios, que el corte ocurra en la petición ciento diez en lugar de la cien es irrelevante.

Deja de bastar en el momento en que el número tiene consecuencias contractuales. Si prometes mil llamadas al mes en un plan de pago, si el límite decide una factura o si superarlo tiene efectos legales, necesitas una cuenta exacta, y eso significa un Durable Object por cliente o una contabilidad en el almacén con su reconciliación posterior. Ahí el salto de red que antes era un defecto se convierte en el precio justo de la exactitud.

Lo interesante es que ambos mundos se componen bien, y componerlos es casi siempre mejor que elegir. El binding nativo va delante como filtro barato y absorbe el noventa y nueve por ciento del tráfico abusivo sin coordinar con nadie; solo lo que lo supera llega al contador exacto, que ahora recibe un caudal manejable en lugar de la ráfaga entera. La aproximación protege a la exactitud, y la exactitud sostiene la promesa.