Limitación de Tasa de API

La limitación de tasa se implementa a través de varios algoritmos, cada uno con diferentes ventajas y desventajas. Ventana Fija (Fixed Window): cuenta las solicitudes por ventana definida (por ejemplo, 1,000 solicitudes por hora). Simple pero vulnerable a ráfagas en los límites de la ventana. Ventana Deslizante (Sliding Window): una ventana de tiempo móvil (por ejemplo, 1,000 solicitudes en cualquier período de 60 minutos) elimina las ráfagas en los límites. Cubo de Tokens (Token Bucket): los clientes acumulan 'tokens' a una tasa constante hasta un máximo, y cada solicitud cuesta un token. Permite tráfico en ráfagas hasta el tamaño del cubo mientras impone límites promedio sostenidos, lo más cercano a los patrones de uso del mundo real. Cubo con Fugas (Leaky Bucket): procesa las solicitudes a una tasa fija, poniendo en cola las solicitudes en exceso, lo que suaviza completamente el tráfico pero introduce latencia durante las ráfagas. La mayoría de las plataformas SaaS utilizan Cubo de Tokens o Ventana Deslizante porque equilibran la flexibilidad para patrones de uso legítimos en ráfagas con la protección contra el abuso sostenido o código descontrolado.

Los errores de límite de tasa (HTTP 429 "Too Many Requests") son frecuentemente diagnosticados erróneamente como errores de software en lugar de un comportamiento esperado de la API. El soporte debe: primero verificar si el cliente realmente está excediendo el límite de tasa de su plan (consultar los datos de uso de la API en el panel de administración); educar sobre la respuesta 429 y su encabezado 'retry-after' (la respuesta de la API incluye el tiempo hasta que se aceptará la próxima solicitud; los clientes correctos deben implementar una retirada exponencial (exponential backoff) cuando reciban 429s en lugar de reintentar inmediatamente); investigar si la implementación del cliente está manejando correctamente los límites de tasa (muchos errores de integración provienen de bucles de reintento infinitos que empeoran el problema del límite de tasa); determinar si el cliente tiene una necesidad legítima de un límite de tasa más alto (un cliente empresarial cuyo caso de uso requiere un mayor rendimiento podría justificar un límite personalizado o una actualización de plan); y documentar sistemáticamente las preguntas sobre límites de tasa para determinar si los límites a nivel de plan son apropiados o necesitan ajuste.

Los límites de tasa son una decisión de diseño de producto y comercial, no solo una restricción técnica. Product Ops debe asegurarse de que los límites de tasa estén: documentados explícitamente en la referencia pública de la API (incluyendo límites por endpoint, no solo límites globales); diferenciados por nivel de precios (los clientes con planes superiores reciben límites más altos, lo que crea un beneficio concreto y tangible para las actualizaciones); mostrados en tiempo real a través de un panel de uso en el producto (los clientes deben poder ver su consumo actual frente a su límite, con alertas antes de alcanzar el tope); y acompañados de una ruta de actualización clara (un banner o correo electrónico activado cuando un cliente alcanza el 80% de su límite de tasa los dirige a actualizar en lugar de simplemente fallar con 429s). Las actualizaciones impulsadas por límites de tasa son un motor medible de ingresos de expansión que Product Ops rastrea junto con otros disparadores de expansión.