Una integración envía muchas peticiones y ralentiza a los demás clientes. Limitar el tráfico puede ayudar, pero un contador global también puede bloquear a usuarios que apenas han utilizado la API. El límite necesita una unidad de responsabilidad y una relación con el recurso que protege.
Rate limiting regula el ritmo de solicitudes admitidas. No sustituye los controles de autorización, la validación de entradas ni una decisión sobre cuánto trabajo puede mantener el sistema en ejecución.
Define qué recurso quieres proteger
Una lectura de estado y una exportación completa no consumen necesariamente el mismo esfuerzo. Si ambas cuentan como una petición idéntica, un límite simple puede ser insuficiente para proteger el componente más costoso.
Describe el recurso limitado: llamadas a un proveedor, consultas pesadas, generación de archivos o trabajo de un equipo compartido. Después decide si la política necesita diferenciar operaciones, volumen o coste estimado.
Separa frecuencia y concurrencia. Admitir pocas solicitudes por minuto no evita que se acumulen tareas largas que duran varios minutos. Los jobs asíncronos pueden necesitar un límite de trabajos pendientes y otro de trabajos ejecutándose.
Elige la identidad con la que se cuenta
Para tráfico autenticado, una cuenta o aplicación cliente suele permitir atribuir consumo mejor que una dirección IP. Varias personas pueden compartir una IP, y una misma integración puede utilizar varias.
La identidad debe obtenerse de información verificada. No confíes en una cabecera arbitraria que permita al cliente cambiar de contador. Si existe un proxy, define qué información de origen se acepta y de qué intermediarios confiables.
Puede ser útil combinar límites: uno por cuenta para reparto, otro por operación costosa y otro global para proteger un proveedor compartido. Documenta cuál prevalece y qué ve el cliente cuando se alcanza.
Decide cómo tratar las ráfagas
Un usuario puede realizar varias acciones legítimas al abrir una pantalla. Un sistema de sincronización puede enviar un pequeño lote después de recuperar conexión. No todo pico implica abuso.
| Enfoque | Qué permite observar | Precaución de diseño |
|---|---|---|
| Ventana fija | Consumo dentro de intervalos definidos | Puede concentrar tráfico alrededor de un cambio de ventana |
| Ventana móvil | Uso en un intervalo reciente | Requiere mantener y consultar estado acorde con la precisión elegida |
| Cubo de tokens | Ritmo sostenido con una reserva para ráfagas | Capacidad de ráfaga y reposición deben reflejar el recurso protegido |
| Límite de concurrencia | Trabajo activo al mismo tiempo | No controla por sí solo el volumen acumulado durante el día |
La elección no debe basarse solo en el nombre del algoritmo. Prueba el patrón de llamadas que produce tu aplicación y el comportamiento del destino bajo esa carga.
Devuelve una respuesta que permita recuperarse
El RFC 6585 define HTTP 429 Too Many Requests para indicar exceso de solicitudes. La respuesta puede incluir Retry-After para orientar al cliente sobre cuándo volver a intentarlo. El estándar no impone una única forma de identificar usuarios o contar llamadas.
Explica el límite aplicable sin revelar información de otras cuentas. El cliente necesita distinguir una restricción temporal de un error de permisos o una solicitud inválida.
Define si el trabajo fue aceptado. Cuando se rechaza por límite antes de encolar, repetir puede ser razonable tras la espera indicada. Si existe un resultado incierto de una operación ya iniciada, la recuperación requiere la identidad de la operación y una comprobación de sus efectos.
Comprueba la política con varias instancias
Un contador en la memoria de cada servidor puede permitir más tráfico del previsto cuando la aplicación escala. Decide si el límite es por instancia o compartido, y qué consistencia necesita el estado.
También debes definir qué ocurre si falla el componente que aplica el límite. Admitir todo o rechazar todo tienen consecuencias distintas según el recurso y el tipo de operación. La conducta debe ser una decisión explícita y probada.
No añadas reintentos independientes en todas las capas sin comprobar su efecto combinado. Un cliente, una cola y un SDK pueden terminar repitiendo la misma operación muchas más veces de lo previsto.
Mide el efecto sobre clientes legítimos
Registra rechazos por política, esperas, trabajo completado y saturación del recurso protegido. Usa identificadores operativos adecuados y evita conservar contenido de peticiones para medir consumo.
Prueba una cuenta con ráfagas legítimas junto a otra que mantiene tráfico continuo. Comprueba que los límites se recuperan como está documentado y que la aplicación puede explicar al usuario qué ocurre.
Para diseñar capacidad compartida en una API de datos, comparte con Nexeus Big Data los tipos de operación y las dependencias limitadas. Esa información permite elegir límites que respondan al consumo real y tengan una recuperación comprensible.