Simulador de Política de Límite de Tasa de API

--- name: simulador-de-politicas-de-limite-de-tasa-de-api description: Simula limites de tasa de API antes de implementarlos - token bucket, ventana fija, registro deslizante y contador deslizante, por cliente, endpoint, nivel o global - contra trafico generado o registrado con clientes que reintentan. Muestra quien recibe 429s y por cuanto tiempo, explosiones en limites de ventana fija, rebanos de reintentos, vecinos ruidosos, clientes abusivos que aun pasan y picos sobre la capacidad del backend. Incluye un simulador offline de Python de la biblioteca estandar con --self-test. --- # Simulador de Politicas de Limite de Tasa de API Ayudas a ingenieros de backend y plataforma a elegir limites de tasa con evidencia en lugar de numeros redondos. Un limite que parece seguro en papel ("300 por minuto por clave") puede aun dejar pasar 1.8x eso en un limite de ventana, estrangular una aplicacion movil cuyos miles de usuarios comparten una clave de API, liberar un rebano de reintentos en el segundo de reinicio, y no hacer nada contra un raspador que se mantiene justo por debajo. Describes las politicas y el trafico en un pequeno archivo JSON, lo reproduces, y lees el resultado cliente por cliente y politica por politica. ## Archivos en esta habilidad - `scripts/rate_sim.py` - simula limitadores de token bucket, ventana fija, registro deslizante y contador deslizante con clave por cliente, endpoint, cliente+endpoint o global, con alcance a endpoints y niveles de cliente; genera trafico constante, Poisson o de explosiones (o reproduce un rastro CSV), permite a los clientes reintentar inmediatamente, con retroceso o respetando Retry-After, y reporta 429s, retrasos, fallos, conteos de ventana en el peor caso y observados, picos vs capacidad, hallazgos RL01-RL10 y una respuesta 429 de muestra (solo biblioteca estandar de Python 3.8+) - `references/algorithms.md` - como se comporta cada algoritmo, su peor caso, costo de memoria y cuando elegirlo - `references/policy-design.md` - elegir claves, niveles, numeros, cabeceras y reglas de reintento del cliente; que significan los codigos de hallazgo - `templates/rate-limit-review.md` - la revision para entregar - `examples/orders-api.json` - una API de pedidos publica con una ventana fija por clave, un limite de inicio de sesion y una ventana fija global; cinco clientes incluyendo una clave movil compartida, un socio masivo, un raspador y un rellenador de credenciales - `examples/orders-api-report.md` - la salida real del simulador en ese archivo - `examples/orders-api-tuned.json` - la misma API despues de los arreglos: token buckets por nivel, un token bucket global dimensionado a capacidad ## Flujo de trabajo ### 1. Recopilar las entradas Pregunta por: los limites configurados hoy o propuestos (algoritmo, clave, numeros, que endpoints y que clientes), donde se aplican (puerta de enlace, CDN, aplicacion, Redis), la capacidad del backend en solicitudes por segundo que puede sostener, y el trafico: los clientes legitimos mas grandes y su forma (constante, trabajos por lotes con explosiones, muchos usuarios detras de una clave o una IP NAT), como reintenta cada uno, y cualquier abuso visto en los registros. Los registros de acceso reales superan a las suposiciones: exporta `t,cliente,endpoint` durante 5-15 minutos ocupados y pasalo con `--trace`. ### 2. Ejecutar el simulador ``` python3 scripts/rate_sim.py examples/orders-api.json python3 scripts/rate_sim.py examples/orders-api-tuned.json python3 scripts/rate_sim.py policies.json --trace access-sample.csv python3 scripts/rate_sim.py policies.json --json python3 scripts/rate_sim.py --self-test ``` Salida 0 = sin hallazgos altos, 1 = hallazgos altos (clientes legitimos estrangulados o trafico admitido sobre capacidad), 2 = entrada incorrecta. Sin un shell, razona con `references/algorithms.md`: por clave, compara el pico del cliente por ventana con el limite, el peor caso (2x limite para ventanas fijas, explosion + tasa para buckets) con capacidad, y piensa en que hace cada cliente despues de un 429. ### 3. Leer el resultado - Clientes legitimos primero (RL01): cualquier solicitud fallida o retrasada, y cuanto esperaron. Una clave compartida por los usuarios de una aplicacion necesita su propio nivel o una clave por usuario. - Capacidad (RL03): el segundo admitido pico vs lo que sostiene el backend. Un limite global es lo unico que protege la capacidad; los limites por clave se multiplican por el numero de claves. - Forma (RL04, RL10): las ventanas fijas dejan pasar explosiones en los limites y entregan una ventana completa de una vez; los reintentos sin jitter vuelven todos en el mismo segundo. - Abuso (RL02): un raspador bajo el limite por clave no se detiene con limites; necesita deteccion, autenticacion o un limite por endpoint. - Reintentos (RL05): intentos por solicitud logica por encima de 1.5 significa que los clientes amplifican la carga cuando se estrangulan. ### 4. Ajustar y re-ejecutar Cambia una cosa a la vez y re-ejecuta con el mismo trafico: cambia ventanas fijas a token buckets o contadores deslizantes, agrega niveles con `clients` / `exclude_clients`, dimensiona el bucket global a capacidad (tasa = rps sostenible, explosion = lo que el backend absorbe por un segundo), agrega limites de endpoint para inicio de sesion y llamadas costosas, y acuerda ritmo con socios por lotes. Usa `references/policy-design.md` para los numeros. ### 5. Entregar Completa `templates/rate-limit-review.md`: veredicto, una tabla antes/despues por cliente, los cambios de politica como configuracion, la respuesta 429 y cabeceras, guia para el cliente (Retry-After, retroceso con jitter, maximo de reintentos) y que monitorear despues del despliegue. ## Ejemplo de resultado En `examples/orders-api.json` la clave compartida `mobile-app` alcanza la ventana de 300/minuto por clave: 1,042 de sus 1,839 solicitudes tienen exito solo despues de esperar hasta 60 s (RL01, alto). Respetar Retry-After sin jitter libera 289 reintentos en el segundo 240, asi que el trafico admitido alcanza un pico de 313 req/s contra una capacidad de 80 (RL03, RL10). La ventana fija por clave deja pasar 544 solicitudes en un minuto movil (1.8x, RL04), y el raspador aun logra el 45% de sus llamadas mientras sus reintentos inmediatos lo empujan a 2.67 intentos por solicitud. El limite de inicio de sesion detiene al rellenador de credenciales (40 de 480). En `examples/orders-api-tuned.json` (token buckets por nivel, bucket global 50 req/s + 30 de explosion, ritmo del socio a 2 req/s) los clientes legitimos no ven 429s, el pico es 27 req/s y solo quedan los hallazgos del raspador. ## Reglas - Simula con el trafico que realmente tienes (o un rastro), no un promedio; las explosiones y los reintentos son donde fallan los limites. - Nunca llames seguro a un limite para capacidad a menos que un limite global acote el total. - Trata las solicitudes retrasadas de clientes legitimos como dano, no como exito. - Siempre devuelve 429 con Retry-After, agrega jitter, y di a los clientes como retroceder. - Los limites de tasa no son proteccion contra abuso por si solos; di cuando se necesitan autenticacion, deteccion de bots o reglas WAF. - Los resultados son un modelo: confirma con metricas de la puerta de enlace despues del despliegue y mantén los limites en configuracion, no en codigo.