Rate limits e quote

Rate limits e quote sono una meccanica fondamentale per la gestione della domanda di risorse condivise: CPU, rete, database, code, API esterne. L'obiettivo è la giustizia (fairness), la prevedibilità dello SLO e la protezione contro i picchi, gli abusi e il «noisy neighbor».

1) Concetti di base

Rate limit - Limita l'intensità delle query/operazioni (req/s, msg/min, byte/s).
Burst è un picco a breve termine valido sopra il rate medio.
Quota è il limite di tempo per finestra (documenti/ore, GB/mese).
Concurrency cap - Limita le operazioni simultanee (query simultanee/jobs).
Scope è l'ambito di applicazione: per-tenant, per-user, per-token, per-endpoint, per-IP, per-region, per-feature.

2) Algoritmi di limitazione

2. 1 Token Bucket (secchio di token)

Le opzioni sono «rate» (token/secondi), «burst» (dimensione secchio).
Funziona come «credito»: i token accumulati consentono picchi brevi.
Adatto per API esterne e query personalizzate.

2. 2 Leaky Bucket (secchio fluente)

Fluidifica il flusso a velocità costante.
Ottimo per alleggerire il traffico a backend sensibili.

2. 3 Fixed/Sliding Window

Fissed window: semplice, ma vulnerabile al cambio di finestra.
Sliding window: più preciso, ma più costoso calcolando.

2. 4 GCRA (Generic Cell Rate Algorithm)

L'equivalente di Token Bucket in termini di tempo di arrivo virtuale.
Accurato e stabile per i limitatori distribuiti (stato meno conflittuale).

2. 5 Concurrency Limits

Vincola le operazioni in esecuzione contemporaneamente.
Protegge contro l'esaurimento dei pool di flussi/connessioni e «head-of-line blocking».

3) Dove applicare i limiti

Al confine (gateway L7/API): barriera principale, guasto rapido (429/503), controlli a basso costo.
All'interno dei servizi: caps aggiuntivi per operazioni pesanti (esporti, report, trasformazioni).
All'uscita dei sistemi esterni: limiti individuali di terze parti (anti-penalty).
In coda/worker: fairness ai pool condivisi.

4) Scorci e priorità (multi-tenant)

Иерархия: Global → Region → Tenant/Plan → User/Token → Endpoint/Feature → IP/Device.
Priority-aware: VIP/Enterprise ottiene più «burst» e peso, ma non distrugge le SLO comuni.
Composizione dei limiti: tolleranza totale = 'min (globale, regionale, tenante, utente, endpoint)'.

5) Quote di volume

Quote giornaliere/mensili: documenti/giorno, GB/mese, messaggi/min.
Soglie morbide/rigide: avvertenze (80/90%) e stop rigido.
Roll-up - Conteggio degli oggetti (tabelle, file, eventi) e output.

6) Limitatori distribuiti

Requisiti: ritardo basso, coerenza, resistenza ai guasti, scalabilità orizzontale.

Locale + sync probabilistic: secchi di chard locali + sincronizzazione periodica.
Central store: Redis/KeyDB/Memcached с LUA/atomic ops (INCR/PEXPIRE).
Sharding: chiavi della vista «limit: {scope}: {id}: {window}» con distribuzione uniforme.
Clock skew - Memorizza la verità sul server limitatore anziché sui client.
Idempotenza: le chiavi di transazione (Idempotency-Key) riducono i falsi prelievi.

7) Anti-abuse e protezione

Per-IP + device fingerprint per endpoint pubblici.
Proof-of-Work/CAPTCHA in caso di anomalie.
Slowdown (throttling) invece di guasto completo quando UX è più importante (suggerimenti di ricerca).
Adattative limits: riduzione dinamica delle soglie per incidenti/degrado costoso.

8) Comportamento client e protocollo

Codici: '429 Too Many Recests' (rate),' 403 '(quota/piano superata),' 503 '(degrado di protezione).

• «Retry-After: » - quando riprovare.

• `RateLimit-Limit: ;w=`
• `RateLimit-Remaining: `
• `RateLimit-Reset: `
• Backoff: esponenziale + jitter (full jitter, equal jitter).
• Idampotenza: titolo «Idempotency-Key» e ripetibilità delle operazioni sicure.
• Timeout e annulla - Interrompere correttamente le query in sospeso per non «catturare» i limiti.

9) Osservabilità e test

Теги: `tenant_id`, `plan`, `user_id`, `endpoint`, `region`, `decision` (allow/deny), `reason` (quota/rate/concurrency).
Metriche: larghezza di banda, failover, p95/p99 ritardi limitatori, hit ratio cache chiavi, distribuzione pianificata.
I loghi di verifica sono le cause dei blocchi, il top delle chiavi rumorose.
I test sono i profili di carico «sega/burst/platea», il caos - il guasto di Redis/Shard, la rassincronizzazione dell'orologio.

10) Integrazione con il bollettino

I contatori Usage vengono assemblati al limite, aggregati con batch (ogni N min) con idipotenza.
Il riepilogo dei piani è un sovraccarico o un aumento temporaneo del piano.
Soluzione temporanea - Comprimere usage vs invoice; Gli alert sul delta.

11) Fairness all'interno (code, worker)

Weighted Fair Queuing/DRR: distribuzione delle slot tra gli affittuari in base al peso del piano.
Per-tenant worker pools - isolamento rigido VIP/rumoroso.
Admision control: errore prima dell'esecuzione se le quote sono esaurite; le code non si gonfiano.
Caps su concertency - Limita i giubbotti pesanti simultanei.

12) Profili di piano tipici (esempio)

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) Riferimento architettonico (schema verbale)

1. Edge/API gateway: TLS è in grado di estrarre il contesto (tenant/plan), di controllare i limiti/le quote, di assegnare i titoli di - /trace.
2. Policy Engine: regole di priorità (VIP), soglie adattive.
3. Limiter Store: Redis/KeyDB (atomic ops, LUA), crash delle chiavi, replica.
4. Servizi: limite secondario e caps per operazioni pesanti Idampotenza; code WFQ/DRR.
5. Usage/Billing: raccolta, aggregazione, fattura, alert alle soglie.
6. Osservabilità: metriche/logi/roulotte con tag, dashboard per-tenant.

14) Foglio di assegno prima di vendere

• Sono stati definiti gli scop dei limiti (tenant/user/token/endpoint/IP) e la loro gerarchia.
• L'algoritmo selezionato (Token Bucket/GCRA) e i parametri «rate/burst».
• Implementati concurrency caps e admision control per operazioni pesanti.
• Le intestazioni «RateLimit -» e «Retry-After» sono abilitate; i clienti supportano backoff + jitter.
• Limitatore distribuito e resistente ai guasti (chard, replica, degrado).
• La raccolta Usage è idipotente; il collegamento con il bollettino, gli alert per il sovraccarico.
• Osservabilità: metriche/roulotte/logi con tag, top chiavi «rumorose», alerter's.
• Test: burst, «sega», errore di store, clock skew, inizio freddo.
• Documentazione client: limiti di pianificazione, esempi 429/Retry-After, best pratices retraes.
• Criteri di esclusione: come aumentare temporaneamente i limiti e quando.

15) Errori tipici

Un limite globale senza per-tenant/per-endpoint - «noisy neighbor» rompe tutto lo SLO.
Assenza di «burst»: UX soffre di picchi brevi.
Usare solo una finestra fissa per «doppio colpo al limite della finestra».
Nessuna idipotenza e nessun retro con jitter.
I limiti sono solo al confine, senza caps nei servizi/code, i «tappi» interni.
La non fissazione dei limiti nelle risposte (nessuna Retry-After, « -») non si adatta ai clienti.
Lo stato del limitatore nel database OLTP è stato memorizzato con elevata latitanza e blocchi hot.

16) Scelta rapida della strategia

API pubbliche con picchi: Token Bucket + grande «burst», RateLimit - titoli, CDN/edge cash.
I giubbotti pesanti interni sono concurrency caps + WFQ/DRR, admision control.
Integrazioni con terzi: limiti di uscita separati, buffering/retrai.
Multi-tenente SaaS: gerarchia dei limiti (global→tenant→user→endpoint), priorità VIP, quote mensili.

Conclusione

I buoni rate limits e le quote sono un contratto di sistema tra piattaforma e cliente, ovvero una fetta onesta di risorse, resistenza ai picchi, SLO prevedibili e un bollettino trasparente. Combinare algoritmi (Token/GCRA + concurrency caps), implementare una gerarchia di raggruppamenti, dare titoli e metriche comprensibili e controllare regolarmente gli schemi sotto i profili di traffico reali, in modo che la piattaforma rimanga resistente anche se il carico aumenta in modo aggressivo.