Rate limits y cuotas

Los límites de tasa y cuotas son la mecánica fundamental para gestionar la demanda de recursos comunes: CPU, red, DB, colas, APIs externas. El objetivo es la justicia (fairness), la previsibilidad de SLO y la protección contra las ráfagas, los abusos y el «neighbor noisy».

1) Conceptos básicos

Límite de tasa (rate limit): limita la intensidad de las solicitudes/operaciones (req/s, msg/min, bytes/sec).
Burst es una ráfaga de corto plazo válida sobre la tasa media.
Quota - límite de volumen por ventana de tiempo (documentos/día, GB/mes).
Cap de concurrencia: limita las operaciones simultáneas (consultas/jobs simultáneos).
Scope - ámbito de aplicación: per-tenant, per-user, per-token, per-endpoint, per-IP, per-region, per-feature.

2) Algoritmos de límite

2. 1 Token Bucket (cubo con tokens)

Opciones: 'rate' (tokens/sec), 'burst' (tamaño del cubo).
Funciona como un «crédito»: los tokens acumulados permiten picos cortos.
Adecuado para APIs externas y consultas personalizadas.

2. 2 Bucket Leaky (cubo que fluye)

Suavemente «drena» el flujo a una velocidad constante.
Bueno para suavizar el tráfico a los sensibles backend 'am.

2. 3 Fixed/Sliding Window

Ventana fija: simple, pero vulnerable al «cambio de ventana».
Ventana deslizante: más precisa, pero más cara computacionalmente.

2. 4 GCRA (Generic Cell Rate Algorithm)

El equivalente de Token Bucket en términos de tiempo de llegada virtual.
Preciso y estable para los límites distribuidos (estado menos conflictivo).

2. 5 Concurrency Limits

Restringir las operaciones que se ejecutan simultáneamente.
Protege contra el agotamiento de las agrupaciones de hilos/conexiones y el «bloqueo de head-of-line».

3) Dónde aplicar los límites

En la frontera (puerta de enlace L7/API): barrera principal, falla rápida (429/503), cheques baratos.
Dentro de los servicios: caps adicionales para operaciones pesadas (exportaciones, informes, transformaciones).
En la salida a sistemas externos: límites individuales para terceros (anti-penalty).
En colas/workers: fairness a grupos compartidos.

4) Scoops y prioridades (multi-tenant)

Иерархия: Global → Region → Tenant/Plan → User/Token → Endpoint/Feature → IP/Device.
Priority-aware: VIP/Enterprise obtiene mayor 'burst' y peso, pero no rompe los SLO comunes.
Composición de límites: tolerancia final = 'min (global, regional, tenante, personalizado, endpoint)'.

5) Cuotas por volumen

Cuotas diarias/mensuales: documentos/día, GB/mes, comunicaciones/minas.
Umbrales blandos/duros: advertencias (80/90%) y «parada dura».
Roll-up: contabilidad por objeto (tablas, archivos, eventos) y «borrado» en facturación.

6) Límites distribuidos

Requisitos: baja latencia, consistencia, resistencia a fallas, escala horizontal.

Local + probabilistic sync: cubos chard locales + sincronización periódica.
Central store: Redis/KeyDB/Memcached с LUA/atomic ops (INCR/PEXPIRE).
Sharding: claves de la vista 'limit: {scope}: {id}: {window}' con distribución uniforme.
Clock skew: almacena la «verdad» en el servidor limitador, no en los clientes.
Idempotencia: Las claves de «operación» (Idempotency-Key) reducen las descargas falsas.

7) Anti-abusivo y protección

Per-IP + dispositivo fingerprint para endpoints públicos.
Proof-of-Work/CAPTCHA para anomalías.
Slowdown (throttling) en lugar de un fallo total cuando UX es más importante (consejos de búsqueda).
Adaptive limits: reducción dinámica de umbrales en incidentes/degradaciones costosas.

8) Comportamiento del cliente y protocolo

Códigos: '429 Too Many Requests' (tasa),' 403 '(cuota/plan superado),' 503 '(degradación defensiva).

• 'Retry-After: ' - cuándo intentarlo de nuevo.

• `RateLimit-Limit: ;w=`
• `RateLimit-Remaining: `
• `RateLimit-Reset: `
• Backoff: exponencial + jitter (full jitter, equal jitter).
• Idempotencia: cabecera 'Idempotency-Key' y repetibilidad de operaciones seguras.
• Tiempo de espera y cancelación: interrumpe correctamente las solicitudes suspendidas para no «capturar» límites.

9) Observabilidad y pruebas

Теги: `tenant_id`, `plan`, `user_id`, `endpoint`, `region`, `decision` (allow/deny), `reason` (quota/rate/concurrency).
Métricas: ancho de banda, porcentaje de fallos de 429/403/503, p95/p99 latencia límite, hit ratio caché de claves, distribución por planes.
Registros de auditoría: las razones de los bloques, la parte superior de las claves «ruidosas».
Pruebas: perfiles de carga «sierra/burst/meseta», caos - fallo de Redis/shard, resincronización del reloj.

10) Integración con facturación

Los medidores de uso se ensamblan en la frontera, agregados por batches (cada N min) con idempotencia.
Resumen de los planes: sobrecostos → sobrecostes o aumentos temporales del plan.
Discrepancias: conciliación usage vs invoice; alertas en el delta.

11) Fairness dentro (colas, workers)

Weighted Fair Queuing/DRR: distribución de ranuras entre los inquilinos según el peso del plan.
pools de trabajo Per-tenant: aislamiento rígido VIP/ruidoso.
Control de la administración: denegación antes de la ejecución si se han agotado las cuotas; las colas no se inflan.
Caps on concurrency: limite los jobs pesados simultáneos.

12) Perfiles de planes modelo (ejemplo)

yaml plans:
starter:
rate: 50  # req/s burst: 100 concurrency: 20 quotas:
daily_requests: 100_000 monthly_gb_egress: 50 business:
rate: 200 burst: 400 concurrency: 100 quotas:
daily_requests: 1_000_000 monthly_gb_egress: 500 enterprise:
rate: 1000 burst: 2000 concurrency: 500 quotas:
daily_requests: 10_000_000 monthly_gb_egress: 5000

13) Referencia arquitectónica (esquema verbal)

1. Edge/API gateway: TLS → extraer el contexto (tenant/plan) → comprobar los límites/cuotas → colocar los encabezados RateLimit- → logs/trace.
2. Motor de políticas: reglas de prioridad (VIP), umbrales de adaptación.
3. Tienda limitada: Redis/KeyDB (ops atómicos, LUA), charding de claves, replicación.
4. Servicios: límite secundario y caps para operaciones pesadas; idempotencia; colas con WFQ/DRR.
5. Usage/Billing: recogida, agregación, factura, alertas en los umbrales.
6. Observabilidad: métricas/logs/tracks etiquetados, dashboards per-tenant.

14) Lista de verificación antes de la venta

• Se han definido los scops de límites (tenant/user/token/endpoint/IP) y su jerarquía.
• Se seleccionó el algoritmo (Token Bucket/GCRA) y los parámetros 'rate/burst'.
• Implementado concurrency caps y control admission para operaciones pesadas.
• Se incluyen los titulares 'RateLimit-' y 'Retry-After'; los clientes admiten backoff + jitter.
• El limitador es distribuido y resistente a fallas (chardas, replicación, degradación).
• La colección usage es idempotente; un paquete con facturación, alertas para sobrecostos.
• Observabilidad: métricas/tracks/logs etiquetados, llaves «ruidosas» superiores, alerter's.
• Pruebas: burst, «saw», falla de stor, clock skew, inicio frío.
• Documentación para clientes: límites por planes, ejemplos de 429/Retry-After, mejores prácticas de retrés.
• Política de excepciones: cómo elevar temporalmente los límites y cuándo.

15) Errores típicos

El límite global sin per-tenant/per-endpoint - «noisy neighbor» rompe todos los SLO.
Ausencia de 'burst': UX sufre en ráfagas cortas.
El uso de sólo una ventana fija → «doble impacto en el borde de la ventana».
No hay idempotencia y retraídas con el jitter → una tormenta de repeticiones.
Límites sólo en la frontera, sin caps en los servicios/colas → «tapones» internos.
No hay límites en las respuestas (no hay 'Retry-After', 'RateLimit-') → los clientes no se adaptan.
Almacenar el estado del limitador en la DAB OLTP → alta latencia y bloqueos en caliente.

16) Selección rápida de la estrategia

API públicas con picos: Token Bucket + gran 'burst', RateLimit- encabezados, CDN/edge caché.
Frijoles pesados internos: concurrency caps + WFQ/DRR, control de admision.
Integraciones con terceros: límites de salida individuales, amortiguación/retrés.
SaaS multi-tenant: jerarquía de límites (global→tenant→user→endpoint), priorización VIP, cuotas por mes.

Conclusión

Buenos límites y cuotas son el contrato de sistema entre la plataforma y el cliente: cuota de recursos honesta, resistencia a las ráfagas, SLO predecibles y facturación transparente. Combine algoritmos (Token/GCRA + concurrency caps), implemente una jerarquía de scops, dé títulos y métricas claras, y revise regularmente los circuitos bajo perfiles de tráfico reales, para que la plataforma se mantenga estable incluso con un aumento agresivo de la carga.