Rate limiting

El rate limiting (o limitación de tasa) es el mecanismo que controla cuántas peticiones puede enviar un cliente a una API dentro de una ventana de tiempo determinada, por ejemplo 100 llamadas por minuto. Cuando se supera ese cupo, el servidor responde con un código HTTP 429 (Too Many Requests) y, en general, rechaza las peticiones excedentes hasta que la ventana se reinicia.

Su propósito es proteger la infraestructura: evita que un solo cliente, un bug en un bucle o un ataque sature los recursos y degrade el servicio para todos. También permite a un proveedor repartir la capacidad de forma justa entre todos sus consumidores y, muchas veces, monetizar el acceso por niveles de plan.

En el ecosistema de plataformas como Salesforce, la limitación de tasa es uno de los controles que enmarcan cualquier integración seria. Cuando un proyecto sobre Salesforce consume APIs externas o expone las propias, el rate limiting define el ritmo seguro al que pueden hablar los sistemas sin romperse entre sí.

Cómo funciona en la práctica

El servidor lleva una cuenta de las peticiones que recibe de cada cliente, normalmente identificado por su clave de API, su token o su dirección IP. Si el cliente está dentro del cupo, la petición se procesa con normalidad; si lo excede, se la rechaza con un 429 sin consumir recursos de cómputo pesados. Muchas APIs acompañan la respuesta con cabeceras informativas como `X-RateLimit-Remaining` (cuántas llamadas quedan) y `Retry-After` (cuántos segundos esperar antes de reintentar), lo que permite a un cliente bien programado autorregularse en vez de seguir golpeando.

Detrás existen varios algoritmos clásicos, cada uno con un compromiso distinto entre simplicidad y precisión:

• Token bucket: un balde se llena con fichas a ritmo constante y cada petición consume una; permite ráfagas cortas mientras haya fichas acumuladas. Es el más usado por su flexibilidad.
• Leaky bucket: las peticiones salen a un ritmo fijo, como agua por un agujero; suaviza los picos pero no premia la inactividad previa.
• Fixed window: se cuenta por bloques de tiempo cerrados (por minuto, por hora); es simple pero sufre el problema del borde, donde dos ráfagas pegadas al cambio de ventana duplican el tráfico real.
• Sliding window: una ventana deslizante que corrige ese efecto de borde a cambio de más cómputo.

Por qué le importa al negocio (y no solo a TI)

Aunque suene técnico, el rate limiting tiene consecuencias muy concretas. Una sincronización nocturna que vuelca pedidos a Salesforce puede fallar a la mitad si dispara más llamadas de las permitidas y el proveedor empieza a devolver 429. El resultado visible para el negocio es datos desactualizados, reportes incompletos o un webhook que deja de notificar. Por eso, dimensionar bien los límites y manejar los reintentos es parte de cualquier integración estable, no un detalle opcional.

Ejemplo concreto en Argentina y LATAM

Pensemos en un e-commerce argentino que consulta la API de un proveedor de pagos para verificar el estado de cada transacción. En un día de alta demanda (un CyberMonday, por ejemplo) el sistema intenta consultar miles de operaciones por minuto. Si supera el límite del proveedor, las respuestas empiezan a llegar como 429 y algunos clientes ven su pago "pendiente" cuando en realidad ya se aprobó. La solución correcta no es insistir más rápido, sino aplicar backoff exponencial: ante un 429, esperar, reintentar con pausas crecientes y respetar la cabecera `Retry-After`. Lo mismo aplica al integrar WhatsApp Business API, AFIP para facturación electrónica o cualquier servicio que cobra y protege su capacidad por cupos.

Errores comunes que conviene evitar

• Tratar el 429 como un fallo definitivo en lugar de un "esperá y reintentá": se pierden datos que sí podían recuperarse.
• Ignorar las cabeceras `Retry-After` o `X-RateLimit-*` y reintentar de inmediato, lo que agrava la situación.
• No distinguir el rate limiting (límite de ritmo, reversible esperando) de una cuota total (límite de volumen por día o mes, que no se libera reintentando).
• Confundir el control de tráfico con los governor limits internos de una plataforma, que son otra capa de protección.

En qué se diferencia de conceptos parecidos

En síntesis, el rate limiting es una defensa silenciosa que mantiene a las APIs disponibles y predecibles. Entenderlo permite diseñar integraciones que se comportan bien bajo presión, recuperan datos sin perderlos y conviven en paz con los límites que cada proveedor impone para cuidar su servicio.