L'essenziale
Secondo diverse fonti specializzate, un limitatore di velocità distribuito correttamente implementato (conteggio atomico, cache di fallback locale) in genere aggiunge meno di un millisecondo per richiesta. Il gateway Aurabase segue esattamente questo schema: la cassa governor per anti-DoS locale, uno script Lua Redis atomico per il conteggio distribuito tra le istanze, una cache moka fallback se Redis non è disponibile. Il circuito dell'interruttore riduce la latenza percepita in caso di guasto anziché aggiungerla: cortocircuita l'attesa per un timeout completo. Ad oggi non sono stati pubblicati dati sulla latenza di Aurabase: ecco perché e come funziona effettivamente il meccanismo.
Anti-DoS e anti-cascading fail, due problemi distinti
La limitazione della velocità protegge il tuo backend dal traffico eccessivo, legittimo o meno: risponde alla domanda "questo chiamante ha il diritto di inviare questa richiesta adesso?" ". L'interruttore protegge il tuo backend da un servizio già downstream: risponde a "questo servizio ha mai dimostrato di non rispondere, dovremmo almeno provarci?" ". Confonderli porta a sottodimensionare l’uno o l’altro.
Sul gateway Aurabase, entrambi risiedono nello stesso stack middleware ma su piani diversi: la limitazione della velocità IP viene eseguita prima dell'autenticazione (anti-DoS puro, nessuna query SQL di fatturazione emessa per traffico non autenticato), mentre l'interruttore protegge le chiamate in uscita ai servizi interni o ai provider LLM.
Il costo dipende interamente dall'implementazione, non dal principio
Secondo Tyk e le guide dell'ecosistema APISIX, un conteggio distribuito ben progettato su Redis (operazioni atomiche, script Lua, TTL nativo) in genere aggiunge 1-3 ms di latenza, con un impatto p99 inferiore al millisecondo nei casi meglio ottimizzati. Al contrario, Zuplo documenta che un limitatore di velocità centralizzato mal posizionato può aggiungere decine di millisecondi a ciascuna richiesta: questa discrepanza si riflette direttamente nel tuo p99.
Questi intervalli provengono da guide tecniche pubbliche (Tyk, Zuplo, ecosistema Apache APISIX), non da un protocollo di misurazione comune. Indicano un ordine di grandezza e un principio architettonico – conteggio atomico e locale piuttosto che sincrono e centralizzato – non una figura da riprodurre come su un’infrastruttura diversa.
Come funziona effettivamente la limitazione della velocità in aura-gateway
Il gateway Aurabase utilizza il governor crate (algoritmo del token bucket) come limitatore di fallback locale, abbinato al conteggio distribuito tramite Redis per condividere lo stato tra diverse istanze del gateway. Il conteggio distribuito passa attraverso uno script Lua eseguito atomicamente sul lato Redis (INCRBY + EXPIRE in una singola operazione di rete), non attraverso un viaggio di andata e ritorno di lettura e scrittura che introdurrebbe una finestra di concorrenza.
Se Redis diventa non disponibile, il gateway passa automaticamente al limitatore locale governor, con una cache moka (max 1.000.000 di voci, scadenza a 300 secondi di inattività) per evitare di ricreare un limitatore su ogni richiesta. Questo fallback è osservabile: ogni interruttore incrementa un contatore Prometheus dedicato, in modo che il team sappia quando il limite effettivo diventa nuovamente N istanze × limite (altrimenti degrado silenzioso dell'isolamento tra istanze).
Il gateway distingue la limitazione della velocità anti-DoS in base all'IP (prima dell'autenticazione) dalla limitazione della velocità in base al progetto/chiave API/quota utente (dopo l'autenticazione, con attestazioni JWT disponibili): due middleware separati nello stack, ciascuno con la propria granularità.
L'interruttore: tre stati, una finestra scorrevole
Il circuito dell'interruttore Aurabase (aura_core::circuit_breaker, condiviso tra il gateway e aura-ai per il fallback tra i provider LLM) segue tre stati classici: Closed, Open, HalfOpen — con un conteggio degli errori in una finestra temporale scorrevole anziché un contatore che non si ripristina mai.
Un dettaglio di implementazione che conta in produzione: il passaggio a HalfOpen consente solo una richiesta di sonda alla volta (anti tuono-herd) — senza questa guardia, tutte le richieste pendenti si precipiterebbero contemporaneamente al servizio appena riaperto, ricreando immediatamente il fallimento che stavamo cercando di evitare.
Dove questi middleware vengono eseguiti nel gateway
Lo stack middleware del gateway Aurabase segue un ordine preciso, verificato nel codice: identificatore della richiesta → log di accesso → limitazione della velocità per IP → autenticazione → limitazione della velocità per attore/quota → interruttore → proxy al servizio di destinazione. Ciascuna fase rifiuta il traffico indesiderato il prima possibile, prima di incorrere in costi di elaborazione più elevati a valle.
Leggi l'articolo completo: piano dati vs piano di gestione nel gateway Aurabase
Perché qui non vengono pubblicati i dati di Aurabase
L'implementazione viene verificata riga per riga nel codice sorgente del gateway. Ma nessun protocollo di misurazione riproducibile è stato ancora eseguito e pubblicato su questa specifica infrastruttura: pubblicare una cifra non misurata significherebbe ripetere l’errore di numeri di marketing non forniti che ci rifiutiamo di riprodurre. Consulta la nostra metodologia di benchmark completa per ciò di cui abbiamo bisogno prima di rilasciare un dato sulle prestazioni.