Rate limits e quotas

Rate limits e quotas são uma mecânica fundamental de gerenciamento de demanda de recursos compartilhados, como CPU, rede, banco de dados, filas, APIs externas. O objetivo é justiça (fairness), previsibilidade do SLO e proteção contra ressalvas, abusos e «noisy neighbor».

1) Conceitos básicos

Rate limit - limite de intensidade de consultas/operações (req/s, msg/min, bytes/segundos).
Burst é um pico aceitável de curto prazo acima do rate médio.
Cota é o limite por janela de tempo (documentos/dia, GB/mês).
Concurrency cap - Limitar as operações simultâneas (consultas simultâneas/jobs).
Scope - Área de aplicação: per-tenant, per-user, per-tocen, per-endpoint, per-IP, per-region, por-função.

2) Algoritmos de limitação

2. 1 Tocen Bucket (balde de Tóquio)

Parâmetros: 'rate' (tokens/segundos), 'burst' (tamanho do balde).
Funciona como um «crédito»: os tokens acumulados permitem picos curtos.
Adequado para APIs externas e consultas personalizadas.

2. 2 Leaky Bucket (balde fluente)

Suavemente «flutua» o fluxo a uma velocidade constante.
Bom para suavizar o tráfego para backend sensíveis.

2. 3 Fixed/Sliding Window

Fixed window: simples, mas vulnerável à «mudança de janela».
Sliding window: mais preciso, mas mais caro computadoramente.

2. 4 GCRA (Generic Cell Rate Algorithm)

O equivalente a Tocen Bucket em termos de horário virtual de chegada.
É preciso e estável para limitadores distribuídos (estado menos conflituoso).

2. 5 Concurrency Limits

Limite as operações simultâneas.
Protege contra a exaustão de poóis de fluxo/conexões e «head-of-line blocking».

3) Onde aplicar os limites

Limite (L7/API): barreira principal, falha rápida (429/503), verificações baratas.
Dentro dos serviços: caps adicionais para operações pesadas (exportações, relatórios, transformações).
Na saída para sistemas externos: limites individuais para terceiros (anti-penalty).
Na fila/worker: fairness para os grupos compartilhados.

4) Escopos e prioridades (multi-tenant)

Иерархия: Global → Region → Tenant/Plan → User/Token → Endpoint/Feature → IP/Device.
Priority-aware: VIP/Enterprise ganham mais 'burst' e peso, mas não quebram SLO compartilhado.
Composição de limites: tolerância final = 'min (global, regional, tenante, personalizado, endpoint)'.

5) Quotas de volume

Cotas diárias/mensais: documentos/dia, GB/mês, mensagens/min

Liminares suaves/rígidos: avisos (80/90%) e «rígido».
Roll-up: contabilidade de objetos (tabelas, arquivos, eventos) e «retirada» em cartaz.

6) Limitadores distribuídos

Requisitos: atraso baixo, coerência, resistência a falhas, escala horizontal.

Local + propabilistic sync: baldes de chard local + sincronização periódica.
Central store: Redis/KeyDB/Memcached с LUA/atomic ops (INCR/PEXPIRE).
Sharding: chaves da vista 'limit: Se você quiser uma distribuição uniforme.
Clock skew: Armazenar «verdade» em um servidor limitador, não em clientes.
Idempotidade: As chaves de operações (Idempotency-Key) reduzem os débitos falsos.

7) Anti-Abuse e proteção

Per-IP + device fingerprint para endpoint públicos.
Proof-of-Work/CAPTCHA para anomalias.
Slowdown (throttling) em vez de falha total quando o UX é mais importante (dicas de busca).
Adaptative limits: redução dinâmica de liminares de incidentes/degradações caras.

8) Comportamento do cliente e protocolo

Códigos: '429 Too Many Requests' (rate),' 403 '(quociente/plano ultrapassado),' 503 '(degradação de proteção).

• 'Retry-After: ' - quando tentar novamente.

• `RateLimit-Limit: ;w=`
• `RateLimit-Remaining: `
• `RateLimit-Reset: `
• Backoff: exponencial + jitter (full jitter, equal jitter).
• Idempotidade: título «Idempotency-Key» e repetibilidade de operações seguras.
• Tempo e cancelamento: Interromper as solicitações pendentes corretamente para não «capturar» os limites.

9) Observabilidade e testes

Теги: `tenant_id`, `plan`, `user_id`, `endpoint`, `region`, `decision` (allow/deny), `reason` (quota/rate/concurrency).
Métricas: largura de banda, proporção de falhas de 429/403/503, p95/p99 atrasos de limitador, hit ratio cachê de chaves, distribuição de planos.
Logs de auditoria: razões dos blocos, chaves mais barulhentas.
Testes: perfis de carga «pilha/bursta/platô», caos - falha Redis/shard, relógio de relógio.

10) Integração com o Billing

Contadores Usage são coletados na fronteira, agregados por batches (cada N min) com idumpotência.
Resumo dos planos: excesso de valor ou elevação temporária do plano.
Discrepâncias: usage vs invoice; Alertas para o delta.

11) Fairness dentro (filas, workers)

Weighted Fair Queuing/DRR: distribuição de slots entre os inquilinos de acordo com o peso do plano.
Per-tenant worker pools: isolamento rígido VIP/ruído.
Controle de adesão: falha antes de ser executado se as quotas estiverem esgotadas; as filas não se inflam.
Caps em concurrency - Limitar os pesados simultâneos.

12) Perfis de planos típicos (exemplo)

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) Referência arquitetônica (padrão verbal)

1. Edge/API Gateway: O TLS → extrair o contexto (tenant/plano) → verificar os limites/quotas → definir os títulos RateLimit - → logs/trace.
2. Policy Engine: regras de prioridade (VIP), liminares adaptáveis.
3. Limiter Store: Redis/KeyDB (atomic ops, LUA), churrasqueira, replicação.
4. Serviços: limite secundário e caps para operações pesadas; Idimpotência; filas com WFQ/DRR.
5. Usage/Billing: coleta, agregação, fatura, alertas.
6. Observabilidade: métricas/logs/trailers com marcas de formatação, dashboard per-tenant.

14) Folha de cheque antes de vender

• São definidos scops de limites (tenant/user/tocen/endpoint/IP) e sua hierarquia.
• O algoritmo selecionado (Tocen Bucket/GCRA) e as opções 'rate/burst'.
• Implementados concurrency caps e adesion control para operações pesadas.
• As manchetes 'RateLimit' e 'Retry-After' estão ativadas; clientes suportam backoff + jitter.
• Limite distribuído e resistente a falhas (chardes, replicação, degradação).
• A coleta usage é idimpotente; A ligação com o Billing, os alertas de excesso.
• Observabilidade: métricas/trailers/logs com marcas, top chaves «ruidosas», alerter's.
• Testes: Burst, «bila», estore falhado, clock skew, início frio.
• Documentação para clientes: limites de planos, exemplos 429/Retry-After, best pratices de retais.
• Política de exceções: como aumentar temporariamente os limites e quando.

15) Erros típicos

Limite global sem per-tenant/per-endpoint - «noisy neighbor» quebra todo o SLO.
Falta de 'burst': UX sofre em picos curtos.
Usar apenas uma janela fixa → «duplo impacto no limite da janela».
Não há Idempotação e Retrações com Jitter → tempestade de repetições.
Limites apenas na fronteira, sem caps em serviços/filas → «engarrafamentos» internos.
A não fixação de limites nas respostas (não há «Retry-After», «RateLimit -») → os clientes não se adaptam.
Armazenamento do estado do limite em um banco de dados OLTP → alta latência e bloqueios «quentes».

16) Escolha rápida de estratégia

API público com picos: Tocen Bucket + grande 'burst', RateLimit - títulos, CDN/edge kesh.
Os veiculos internos pesados são concurrency caps + WFQ/DRR, adpressor controle.
Integração com terceiros: limites de saída individuais, tampão/retraí.
Multi-tenante SaaS: hierarquia de limites (global→tenant→user→endpoint), priorização VIP, quotas mensais.

Conclusão

Bons rate limits e quotas são um contrato de sistema entre a plataforma e o cliente, como uma proporção justa de recursos, resistência a picos, SLO previsível e um acervo transparente. Combine algoritmos (Tocen/GCRA + concurrency caps), implemente uma hierarquia de cúmulos, dê cabeçalhos e métricas compreensíveis e verifique rotineiramente os circuitos sob perfis reais de tráfego - de modo que a plataforma permaneça resistente, mesmo com o aumento agressivo da carga de trabalho.