Progettazione rate limiter'ov

1) Perché rate limiting

Rate limiting protegge la disponibilità e l'economia dell'API: ferma i floud, i «burst» retraes, credential stuffing, protegge le operazioni costose (transazioni in denaro, generazione di report), allenta il carico sui sistemi dipendenti (OBD/provider). Un buon design dà equità (fairness), prevedibilità di latitanza e SLO chiaro.

Obiettivi chiave

Stabilità RPS e protezione del backend dal sovraccarico.
Elasticità guidata (burst allowance).
Differenziazione dei clienti (per utente/per-organizzazione/per-chiave/per-IP/per-regione).
Il modello di valore è «prezzi» diversi per operazioni diverse.

2) Tipi di limiti

Limiti RPS: richieste al secondo/minuto.
Quote: bilancio totale in un periodo (giorno/mese).
Concorrenza: operazioni simultanee (checkout, heavy job).
Velocità/banda: byte/secondi (caricamento/caricamento).
Limiti ponderati: «costo» di una richiesta di complessità (ad esempio, GraphQL complexity, dimensioni batch).
Adattivi: aumentano in caso di anomalie (attività sospetta/errori 401/403/5xx).

3) Algoritmi e quando applicarli

3. 1 Fixed window counter

Semplice: contatore per intervallo (ad esempio, 100 r/min).
I vantaggi sono il costo minimo. Contro, «borghi» ai confini della finestra.

Quando: pannelli ammiraglio, bassa precisione, basso costo.

3. 2 Sliding window (log / counter)

Log memorizza gli indicatori temporali delle ultime richieste, accurati, percorsi di memoria.
Counter: media di due finestre adiacenti (rolling), compromesso di precisione e prezzo.

Quando: API pubbliche di traffico medio, serve fluidità senza matematica complessa.

3. 3 Token bucket

Opzioni: velocità «r» (token/secondi) e capacità «b» (burst). Ogni richiesta brucia un token.
I vantaggi sono burst allowance naturale, semplice realizzazione. Contro, nessuna uniformità.

Quando: quasi sempre per RPS, se si desidera «fuoco» entro «b».

3. 4 Leaky bucket (drip)

Una coda da cui «fuoriesce» a velocità fissa.
Pro, flusso di uscita regolare. Contro, più ritardi.

Quando: antialiasing ai provider «fragili» esterni.

3. 5 GCRA (Generalized Cell Rate Algorithm)

• «TAT _ next = max (TAT _ current, now) + 1/r», richiesta accettata se «now <= TAT _ current + burst/r».
• I vantaggi sono rigorosi, precisi, con poca memoria (TAT). I contro sono più difficili da capire.

Quando: servono controlli rigorosi e fluidi, limiti distribuiti.

3. 6 Semafori competitivi

Conteggio attività attive ingresso - se «biglietti» sono disponibili; La via d'uscita è la liberazione.
Quando: operazioni long-running, flussi, WebSocket, download.

4) Modello chiavi limite

• `client_id`/`api_key`/`user_id`/`org_id`
• «IP/ASN/geo» (protezione severa)
• «endpoint/method» (rotte calde)
• «scope/plan/tier» (monetizzazione)
• «idempotency _ key» (operazioni write)
• Utilizzare le gerarchie: prima le chiavi rigorose per la chiave, poi per l'organizzazione, poi quelle globali.

5) Peso query (cost model)

• GraphQL: complessità nei campi x profondità.
• REST- Dimensione della risposta/richiesta, tipo di operazione (read = 1, write = 3, report = 10).
• Batch: `cost = min(n, cap)`.
• Limitiamo i token, non le query: 'budget - = cost (q)'.

6) Implementazione distribuita

6. 1 Storage

In-process: ultra-veloce, ma non limite totale (valido per i limiti «morbidi» locali).
Lo standard di fatto è Redis. INCR/EXPIRE, script Lua (atomatologia), ZSET per sliding window, chiavi con TTL.
Invoy/NGINX/Kong/Traefik: filtri incorporati; Comodo per il perimetro.
Servizio Mesh - Limiti locali per sidecar + sincronizzazione globale.

6. 2 Atomarietà e corse

Lua in Redis, verifica e incasso in un solo passo.
GCRA - Memorizza un TAT con CAS/script.
Coerenza orologio NTP, timer monouso.
Sharding: hash consistenziale su chiave; Evitate gli hot shard.

6. 3 Distribuzione geografica

Limiti locali nei cluster regionali + globale superiore (coase).
CRDT/replica - Attenzione (ritardi, doppio consumo). Preferibilmente i limiti regionali con riserva.

7) Criteri e priorità

Piani Free/Pro/Enterprise con diverse «r», «b», quote.
Priorità: le rotte «costose» ricevono un limite inferiore o più caro.
Elenchi: allow-list per le integrazioni, deny per ASN/proxy/TOR.
Escalation: al superamento - Abbassiamo il limite, immettiamo proof-of-work/capja/challenge.

8) Esempi di configure

8. 1 Avvoy (HTTP rate limit filter, pseudo)

yaml rate_limit:
domain: public-api descriptors:
- key: api_key rate_limit:
unit: second requests_per_unit: 50 burst: 100
- key: api_key value: payments. write rate_limit:
unit: second requests_per_unit: 5 burst: 10

8. 2 NGINX (lua + Redis, pseudo)

nginx lua_shared_dict limits 10m;

location /api/ {
access_by_lua_block {
local key = ngx. var. arg_apikey.. ":".. ngx. var. request_method.. ":".. ngx. var. uri
-- token bucket in Redis (evalsha)
local allowed, retry_after = ratelimit_allow(key, 50, 100) -- r=50/s, b=100 if not allowed then ngx. header["Retry-After"] = retry_after return ngx. exit(429)
end
}
proxy_pass http://backend;
}

8. 3 Limiti competitivi (pseudocode)

pseudo on_request_start(key):
if redis. incr_with_ttl("sem:" + key, ttl=60) > MAX_CONCURRENCY:
redis. decr("sem:" + key); reject(429)
on_request_finish(key):
redis. decr("sem:" + key)

8. 4 GCRA (pseudocode)

pseudo params: r tokens/sec, burst b tat = redis. get(key) or now allowed_time = tat - (b / r)
if now < allowed_time: reject(429, retry_after = allowed_time - now)
tat_next = max(tat, now) + 1/r redis. set(key, tat_next, ttl = ceil(b/r) + safety)

9) Integrazione con retraes, timeout e circuito breaker

Retry-budget: limitare la quota di retrai al X% del traffico principale.
Jitter: con backoff, aggiungi sempre un jitter - riduce i picchi sincroni.
Circuito breaker: in caso di errori elevati ('5xx', timeouts), ridurre i limiti o tradurre alcune rotte in «read-only».
Hedging con attenzione; tenere conto del costo per non raddoppiare il budget.

10) Osservabilità e controllo

Метрики: `rps_allowed`, `rps_blocked`, `429_rate`, `retry_after_avg`, `burst_used`, `quota_remaining`, `active_concurrency`.
Le etichette, la chiave del limite, la regione, l'endpoint, il piano.
Logi di soluzione (sampled): causa di guasto, contatori correnti, chiave TTL.
Le mappe termiche per chiavi/endpoint, i clienti hot.
Alert: crescita 429-2-5% su rotte critiche, frequenti «esaurimento» di quote, squilibrio dei sardi.

11) Test e convalida

Test dei criteri contrattuali (tabelle se).
Carichi di lavoro: burst (x10 da r), platee lunghe, pattern «sporchi» (slow-POST, lunghe connessioni).
Traffico Chaos: flusso irregolare, clock drivt, discesa Redis/mesh.
A/B-inclusione: canary rollout limiti, soluzioni shadow (logifichiamo ma non blocchiamo) prima di essere attivati.

12) valigette Edge e sottilità

Clock skew: utilizzare «now ()» da un'unica origine (server) anziché dall'intestazione del client.
Idempotency-Key - Per write - riduce l'amplificazione per i retrai.
Operazioni batch - Limitare le dimensioni del battello e il costo totale.
Long-poll/WebSocket - Limitare il numero di canali/iscrizioni e la durata.
Cold start: avvio «caldo» dei contatori/preordini; altrimenti picchi falsi 429.
Le richieste più costose sono limitate fino alla logica aziendale.
TTL: TTL chiavi deve coprire la finestra + scorta (safety margin).

13) Escalation antibot

→ → 429 + «Retry-After» (Capcha/Puzzle) → un blocco temporale.
I segnali sono: device-fingerprint, comportamento cursore/timing, TOR/proxy/hosting.
I politici devono essere determinati e riprodotti per essere forensi.

14) Sicurezza e compliance

Deny-by-default su percorsi critici (write/finanza).
Controllo - Conservare le soluzioni di limitazione per le valigette regolatorie e gli incidenti.
PII - Le chiavi dei limiti non devono essere contenute nei dati personali.

15) Assegno-foglio prod-pronto

• Sono state definite le chiavi dei limiti e il modello cost.
• L'algoritmo selezionato (token bucket/GCRA) e il repository (Redis/gateway).
• Regole per i client tier + fusibili globali.
• Limiti competitivi per operazioni lunghe.
• Retry-budget, backoff con jitter, integrazione con il circuito breaker.
• Dashboard/alert, loghi di soluzioni samplati.
• Attivazione canary e modalità shadow.
• Test di burst, platea di lunga durata, guasti di Redis, clock skew.
• Documentazione client: codice 429, «Retry-After», esempi di backoff esponenziale.

16) TL; DR

Utilizzare token bucket o GCRA con Redis/gateway, progettare le chiavi dei limiti e il costo delle richieste, aggiungere semafori competitivi per operazioni lunghe, integrare con retry-budget e circuito breaker, osservare 429 e «capacità di burst», espandere i limiti attraverso canary/shadow e obbligatoriamente testare i burst e il guasto dello storage.